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NOTICE 


.login: (ISSN 1044-6397) is published bi¬ 
monthly by the USENIX Association. 

The USENIX Association is a not-for-profit 
organization of those interested in UNIX* and 
UNIX-like systems. It is dedicated to fostering 
and communicating the development of 
research and technological information and 
ideas pertaining to advanced computing 
systems, to the monitoring and encouragement 
of continuing innovation in advanced comput¬ 
ing environments, and to the provision of a 
forum where technical issues are aired and 
critical thought exercised so that its members 
can remain current and vital. 
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USENIX Online Library/Index 

What Is It: 

The USENIX online index is an electronically 
available list of papers published by the USENIX As¬ 
sociation and related groups. It contains title, 
author, and related information about papers 
published in USENIX and UNIX-related conference 
and workshop proceedings, newsletters, journals, 
and the like. 

The index is freely available, and is kept as a 
simple ASCII file, in refer/bib format, sorted by 
author. In some cases, electronically readable ver¬ 
sions of full papers or abstracts are also available. 
If a paper is available online, this is indicated in its 
index entry. 

How to Get the Index: 

The index is available online from UUNET, ei¬ 
ther via a mail server or anonymous ftp. The index 
is about 200K, and available only in entirety. To 
get it via electronic mail: 

$ echo send bibliography I \ 
mail uunet!library 

A (non-human) server will automatically break the 
index up into mailable chunks (if necessary), and re¬ 
turn it to the sender of the mail. 

Or, the index can be retrieved via anonymous 
ftp to uunet.uu.net : 

ftp> get library/bibliography my_local_file 
To get a help file: 

$ echo help I mail uunet!library 
To pick up the date the index was last changed: 

$ echo send date I mail uunet!library 
For those unable to reach UUNET, the index is also 
available in hardcopy format from the Association 
office. 

Online Papers and Abstracts: 

We are actively soliciting the donation of pa¬ 
pers and abstracts to include in the library. If you 


have had a paper published in any of the publica¬ 
tions listed below, and you wish to donate the pa¬ 
per, you must provide us with an electronic version 
and give us permission to distribute it. You or your 
employer may retain the copyright if you wish. 

If you wish to donate an abstract, we are 
prepared to type it in for you - all we need is your 
permission. 

Publications Indexed: 

Currently we have indexed all available issues 
of the following: 

USENIX: 

Conference proceedings 
Workshop proceedings 
Computing Systems 
; login: 

European UNIX User Group: 

Conference proceedings 
Newsletters 

Software Tools User Group: 

Conference proceedings 

Australian UNIX User Group: 

Newsletters 

UNIX Review periodical 

We are in the process of incorporating 
Japanese UNIX Society publications to the index. 
Other sources (AFUU, GUUG, NZUSUGI, etc.) are 
being continually evaluated and will be included as 
deemed suitable. 

More Information: 

For additional information about the online in¬ 
dex and library, and/or instructions for donating 
abstracts or papers, contact: 

usenixlindex (index@usenix.org) 

Or contact the Association’s executive office. 


USENIX Supporting Members 

Digital Equipment Corporation 
Open Software Foundation 
AT&T Information Systems 
Quality Micro Systems 
Convex Computer Corporation 
The Aerospace Corporation 
Sun Microsystems, Inc. 

Sybase, Inc. 
mt Xinu 


1990 Board of Directors 
Election Information 

The following 1990 USENIX Board of Direc¬ 
tors’ Candidates’ Statements along with ballots were 
sent to all paid-up members as of March 7, 1990, 
on or about March 12. Members will have until 
April 6 to return their ballots to the Association 
office. The results of the election will be announced 
at the Anaheim Conference and in the next issue of 
;login:. Newly elected directors will take office im¬ 
mediately following the Anaheim conference in 
June. 


March/April 1990 
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Candidate for President 


Stephen C. Johnson 



Biographical Information 

Ph.D. in Mathematics, Columbia University, 1968. 
Joined Bell Labs, 1967, where I worked in computer 
music, psychometrics, computer algebra, computer 
theory, VLSI design. Wrote yacc, lint, and the Port¬ 
able C Compiler. Co-author (with Dennis Ritchie) 
of the first UNIX port. Joined Stardent Computer 
as Vice President in 1986. Joined NCUBE in 1990. 
Member of the USENIX board, 1984-1990, 
Treasurer, 1986-1990. Taught tutorials at USENIX 
and EUUG. 

Position Statement 

For USENIX to succeed, we need to have both a vi¬ 
sion of the future and an attention to the details of 
the present. The details are largely handled by the 
staff; the board’s chief role is making sure that the 
staff is empowered with resources and direction to 
continue our conferences and publications, and that 
the often confusing financial picture doesn’t get out 
of hand. My years of experience as a manager and 
as USENIX Treasurer have given me a detailed 
knowledge of the details and a good working rela¬ 
tionship with the staff. 

My vision of USENIX is as the meeting ground 
of the technical and the practical. UNIX has be¬ 
come the universal base for operating systems; we 
can no longer use UNIX as a simple way to distin¬ 
guish ourselves from ACM or IEEE. USENIX is 
already moving beyond UNIX, and I propose to ac¬ 
celerate this, supporting, for example, Mach and 
Chorus rather than POSIX and yet another BSD 
UNIX, C++ rather than ANSI C, technical innova¬ 
tion rather than standards wars. I also want to see 
USENIX encourage a broader group of 
attendees-men, women, students, neophytes, gurus, 
kernel hackers, and systems administrators, but all 
with a technical, practical orientation. We have a 
lot to gain from diversity, and should be flexible 
enough to accommodate many different peoples’ 
needs. 


In my career, I have combined management 
and timely product delivery with innovation and ac¬ 
tive technical involvement (including papers in 
USENIX and ACM conferences and the Journal). 
Join me so USENIX can go forward with this vision. 
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Candidate for President 


Marshall Kirk McKusick 



Biographical Information 

Kirk McKusick got his undergraduate degree in 
Electrical Engineering from Cornell University. His 
graduate work was done at the University of Cali¬ 
fornia at Berkeley, where he received Masters 
degrees in Computer Science and Business Adminis¬ 
tration, and a Computer Science Ph.D. in the area 
of programming languages. While at Berkeley he 
implemented the 4.2BSD fast file system and was 
involved in implementing the Berkeley Pascal 
system. He currently is the Research Computer 
Scientist at the Berkeley Computer Systems 
Research Group, continuing the development of fu¬ 
ture versions of Berkeley UNIX. He has been a 
member of the USENIX board since 1986. He is a 
member of the editorial board of UNIX Review 
Magazine and a member of ACM, IEEE, and 
USENIX. 

Position Statement 

The goal of the USENIX Association as stated in its 
charter is the “exchange and communication of 
research and technological information and ideas 
pertaining to UNIX and UNIX-related computer 
systems.” The strength of the organization has been 
its emphasis on presenting the leading edge of UNIX 
research and technology. USENIX should continue 
to have conferences and workshops with refereed 
papers and proceedings available at or before the 
conference. I am committed to the new member 
services that we have started in the past two years. 
These include an inexpensive subscription service to 
receive all the USENIX conference and workshop 
proceedings published during the year, an online 
database of past proceedings along with the ability 
to order back copies of the indexed proceedings, 
and the expansion of half to full years membership 
checkoff at the summer conference. I favor 
eliminating the licensing restrictions on the tutorials 
that we offer at our conferences and am pleased that 
USENIX has been able to eliminate the licensing 
restriction on my own BSD tutorial. 

The emergence of the commercial UNIX 
marketplace has necessitated large marketing- 


oriented conferences such as those run by Uni- 
Forum. Although many members of USENIX need 
or want to attend these conferences, USENIX should 
not try to host marketing-oriented conferences. An 
appropriate compromise is to work with UniForum 
to schedule separate conferences that are held at the 
same time and in the same city so that members 
can attend both conferences in a single trip. 

During the past term, I championed the By- 
Laws change to limit tenure on the board; 
enthusiasm and new ideas require new faces on the 
board. I would like to see further changes in the 
election procedures so that the voters have more 
choice than approving the slate of officers picked by 
the nominating committee. For the first time in the 
history of the organization, you have a choice for 
President of the board; I can ask for your vote, not 
your approval. Educational, research, and ad¬ 
vanced commercial development communities have 
a major role in the development and promulgation 
of UNIX. As a researcher at an academic institu¬ 
tion, my viewpoint will perform a key role in 
representing these interests. 


March/April 1990 
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Candidate for Vice President 


Michael D. O’Dell 



Biographical Information 

Mike O’Dell received both his B.S. (1976) and M.S 
(1980) degrees in Computer Science from the 
University of Oklahoma. He has been an avid 
UNIX proponent since writing a PL/I program to 
print Fifth Edition manual pages from a tape of 
nroff(l) output. He later went on to install and run 
the University’s first college-wide timesharing 
system. Upon escaping university, he joined the 
Lawrence Berkeley Laboratory where he survived 
the ARPAnet’s Great TCP Conversion. Currently, 
Mike is living the life of a Consultant after having 
served most recently as the Chief Computer Scien¬ 
tist for an ill-fated start-up company working on a 
GaAs supercomputer. He remains active in the 
areas of networks, operating systems, electronic 
music, and of course, UNIX. 

His recent USENIX activities include: 

• USENIX Board of Directors, Member-at-Large 

• Editor-in-Chief of Computing Systems, the 
USENIX quarterly journal 

• Board of Directors, UUNET Communications 
Corporation 

Position Statement 

I am standing for election to the Board of Directors 
as Vice-President in order to continue serving the 
Association in general, and the Board in particular. 
Our most recent Vice-president, Deborah Scherrer, 
set a very high mark for service in this office and I 
intend to honor the tradition. 

The USENIX Association was founded to pro¬ 
vide services to the technical and professional UNIX 
community, and I remain deeply committed to this 
mission. My Board tenure has been engaging, at 
times amusing, and always rewarding. My role as 
Editor-in-Chief of the journal is one of the most 
gratifying jobs I have ever had, and the new book 
publishing initiative just approved by the Board is 
even more exciting. As a Director of UUNET Com¬ 
munications Corporation, I provide ongoing com¬ 
munication between the Association and its 


inventive offspring. These jobs are all extremely re¬ 
warding and I appreciate the opportunity to serve 
the community in these ways. 

USENIX continues to experiment with services 
and activities: the Professional Development 
Seminars, the new Concurrent Sessions at the Janu¬ 
ary conference, and the new book initiative are all 
examples. I believe the greatest challenge remains 
understanding and refining what makes us different 
from other groups. As UNIX continues to grow in 
popularity, there is a very real risk of the Associa¬ 
tion changing from a group of innovative futurists 
into the protectors of the status quo, or of becoming 
indistinguishable from the ACM or the IEEE. 
These alternatives are utterly unacceptable. 

On the other hand, we have a long, deeply- 
cherished tradition of being the conduit for techni¬ 
cal information exchange within the UNIX com¬ 
munity, and we cannot forsake that role lest we 
disown our birthright. Therefore, the dual challenge 
is to remain a beacon of technical information for 
the newcomers and new converts to UNIX, while at 
the same time continue to move forward as we 
must. Thus far, the Association has avoided success 
disasters - i.e. failures resulting from too much 
success. But as UNIX becomes more mainstream 
(who would have believed that would ever be a seri¬ 
ous concern?) the risks increase and the balancing 
act becomes even more crucial. 

The Association continues to have a wonder¬ 
fully eclectic membership (a short perusal of the 
BOF Board at any conference is ample proof) and I 
feel a deep obligation to not only look after the 
affairs of the Association, but to nurture our reputa¬ 
tion as being THE group focusing on the hard tech¬ 
nical issues of UNIX and Beyond, while maintaining 
our tradition of congeniality and conviviality. 

A final thought - Inventing the future is a FUN 
job. Come to USENIX and share it! 
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Candidate for Secretary 


Rob Kolstad 



Biographical Information 

B.A.Sc. (Computer Science) Southern Methodist 
University, 1974. 

M.S.E.E. (Electrical Engineering) Notre Dame 
University, 1976. 

Ph.D. (Computer Science) Univ. Illinois at U/C, 
1982. 

Software Manager, Sun Microsystems. Co-Program 
Chairman 1985 Winter USENIX Conference. Chair¬ 
man 1988 Winter USENIX Conference. Co- 
Chairperson USENIX 1987 Systems Administrator 
Conference. Frequent speaker at USENIX confer¬ 
ences. Member of USENIX board 1986-1990. Four¬ 
teen years of UNIX experience. 

Position Statement 

The success of Users’ Groups in general depends 
heavily on their correct discernment of their role in 
their particular community. USENIX’s success and 
strength has been achieved in two ways. One way 
USENIX succeeds is by enabling and enhancing 
communication among all levels of UNIX users: 
through conferences, ;login:, the Journal, Usenet 
mapping, UUNET, manual distribution, tutorials, 
and workshops. USENIX must continue to engender 
projects like these and to monitor and improve 
their quality. 

But potentially more important even than com¬ 
munication is innovation. The USENIX board con¬ 
tinually strives to attain and experiment with new 
ideas and projects. Conference chairmen continu¬ 
ally try new ideas: talks that run on a schedule, 
proceedings with work barely two months old, 
works-in-progress sessions, and alternative tracks. 
Few disagree that UUNET and the new workshop 
formats are innovative. This innovation continu¬ 
ally revitalizes the organization and its membership. 
Now that UNIX is older, the distribution of 
members’ experience with it is more diverse. We 
must serve innovation to all our members. 

I believe USENIX should continue to foster the 
positive communications and innovation that are so 


visible to the community. I have worked over the 
last four years to encourage the revival of small 
workshops as vehicles for focused technical gather¬ 
ings, acquired two 75 megabyte distribution tapes of 
public-domain sources, upgraded the presentation of 
conference proceedings, enabled more students to 
attend conferences, and encouraged identification 
and funding of relevant projects. If re-elected, I will 
continue to work to support projects such as these 
and new innovative ones which contribute services 
or products to enhance not only communications 
but also technology within the UNIX community. 
The April 1990 planning meeting will be the next 
milestone on the road to new projects. I will be 
there with new proposals. If reelected, I also intend 
to explore the budget in ever more detail to under¬ 
stand how USENIX can balance the costs and ser¬ 
vices to its users. 


March/April 1990 
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Candidate for Treasurer 


Sharon Murrel 



Biographical Information 

Sharon Murrel has been a member of technical staff 
at AT&T Bell Laboratories for 12 years. After com¬ 
pleting her undergraduate degree at New York 
University and all but her doctoral thesis at the 
State University of New York at Stony Brook, she 
joined the Labs. There she developed a real-time 
satellite system named Parasite with Ted Kowalski 
and wrote a series of experiments and processes us¬ 
ing that system, after which she did a thesis on 
computer conferencing and did receive her PhD 
from StonyBrook. She then wrote monk, a 
database-driven formatting interface to troff. It is 
designed to simplify the end user task, however, its 
main focus has been the development of typograph¬ 
ical databases and the high-level language in which 
they are written. She is now working with the in¬ 
teractive visual editors for tbl and troff, new troff 
preprocessors for layout and placement as well as 
glossaries. All of these new tools are being used to 
produce the AT&T Technical Journal in-house. She 
is now experimenting with new layout primitives 
for troff and with releasing some of her functioning 
tools. Both are difficult tasks. 

Position Statement 

I have now been a member of the USENIX board 
for two years. It takes much of the first year to wet 
ones ears; so by now it is really fun and productive. 
In a fit of enthusiasm, I am standing for the post of 
Treasurer. I admire the successful development of 
the Association from a small, casual group of 
techies to a large, structured, and yet still technical 
organization. The organization remains as strong as 
the technical content of its meetings, tutorials, and 
publications. With the introduction of more techni¬ 
cal workshops and the recent advent of the journal, 
these are constantly improving. The board is now 
launching an effort to publish technical mono¬ 
graphs, which is magnificent technically but may 
not be attractive to most publishers because of its 
limited distribution. 

USENIX must maintain its position as the 
forum for the technical innovations proposed and 


implemented by its increasingly diverse member¬ 
ship. USENIX can and should be innovative, reach¬ 
ing to include technical exchange about new 
languages and new operating systems. I advocate 
more technical workshops, more effort to foster 
communication among the diverse interest groups 
and more funding for novel member projects. I 
have worked with Eric Allman, Lori Grob, and the 
Executive Director, Ellie Young, to organize the 
recent set of concurrent sessions. Attended by 
between 100 and 265 people, these talks provided 
some theory, history, and practical nitty gritty about 
regular expressions, Make, networks, support, 
Nawk, and Perl. This first series can only be 
described as a success in terms of both quality and 
attendance. USENIX hopes to continue this talk 
series and to extend these sessions to provide small 
forums for the informal exchange of technical infor¬ 
mation. 

Educational, research, 

and advanced commercial development communi¬ 
ties play a major role in the development and ac¬ 
ceptance of UNIX. It is important that all of these 
communities be represented on the board. As a 
member of the research community at a small and 
backward, but long-lived UNIX facility, my 
viewpoint will bring a breath of fresh air in 
representing alternate interests. Moreover, the 
board needs an AT&T representative to heckle dur¬ 
ing discussions of the UNIX Operating System’s fu¬ 
ture. 
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Candidate for Director 


Rick Adams 



Biographical Information 

BS in Computer Science, 1979, MS, 1980, Purdue 
University 

Systems Analyst, Purdue University, 1981-82 
Member Technical Staff, RLG/CCI, 1982-83 

Chief Systems Programmer, Center for Seismic 
Studies, 1983-89 

Founder, President, Technical Director, UUNET 
Communications Services, 1989-present 

Editorial Advisory Board, Computing Systems, 1990 

Co-Author !%@:: A Directory of Electronic Mail Ad¬ 
dressing & Networks 

Maintained Usenet B news software, 1982-88 
Maintained BSD UUCP software, 1985-present 

Current interests: communications, networking, 
operating systems 

Invited speaker: INRIA, Paris, France; IX Interna¬ 
tional Conference of the Chilean Computer Science 
Society, Santiago, Chile; and others 

Position Statement 

I have attended a majority of all USENIX board 
meetings since October, 1986. While my participa¬ 
tion at those meetings was presenting reports and 
observing, I learned a great deal about how USENIX 
functions as an organization. This, coupled with 
my three years’ experience as both a UUNET board 
member and the person responsible for UUNET’s 
day-to-day operations greatly enhances my ability to 
serve on the USENIX Board. 

USENIX continues to enjoy financial success. 
While traditionally USENIX has depended heavily 
on volunteer efforts, it’s time for the Association to 
“adopt” successful volunteer efforts like the 
FaceSaver and Terminal Room and consider them 
integral parts of the Association’s services. This 
adoption would ensure the continued availability of 
these services and would allow a continued high 
level of service without the uncertainty that some¬ 
times is present with volunteer efforts. 


This would free volunteers from the operational 
nuisances of providing these proven valuable ser¬ 
vices and allow them to devote their efforts to other 
innovative and potentially successful efforts. 


March/April 1990 
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Candidate for Director 


Peter Collinson 



Biographical Information 

In 1973, after graduating from the University of 
Essex, UK with a B.A. and Ph.D. in Computer Sci¬ 
ence, I took up a post of Lecturer in Computer Sci¬ 
ence at the University of Kent at Canterbury. In 
1976, I found myself running UNIX V6 on a small 
PDP11/40. In 1980, Kent had acquired a VAX 
11/780 and I was responsible for writing the code 
supporting a Cambridge Ring Local Area Network 
for UNIX 32V and later 4.[0123]BSD. This 
predated full commercial availability of Ethernet 
and the invention of sockets. I stopped teaching in 
1983 and headed a support group that was actively 
involved with the development of UNIX on the 
Kent campus. A large part of the effort here has 
been the establishing of the UK Usenet backbone. I 
left the university in 1989 to form my own consul¬ 
tancy firm. The company is dedicated to earning 
enough money to allow me to pursue my own in¬ 
terests: doing whatever, whenever, wherever. 

I have always been interested in user groups. I 
was an early member of the UK group, and became 
its Chairman for a year in 1978. After resigning, I 
stayed on the committee and was a founding 
member of the EUUG. Between 1982 and 1988, I 
served the EUUG in various capacities from rang¬ 
ing from Newsletter Editor to Secretary. 

My USENIX activities include: 

• Invited speaker for the Washington 1987 'Great 
USENIX Snowflake 1 conference. Presented the 
‘Science fiction' paper. 

• EUUG representative to Dallas Winter 1988 
‘The nearest sidewalk is 20 miles away' confer¬ 
ence. 

• Presented paper at San Francisco Summer 1988 
‘People go home by 3pm Friday, so let’s show 
the others a neat video’ conference. Ran and 
judged contest. 

• Attended the Washington Winter 1990 ‘Let's all 
go and bait the Board Candidates' conference. 


* Editorial board member of Computing Systems 

since the start of publication. 

Position Statement 

I am grateful for the opportunity to stand for elec¬ 
tion to the USENIX board since it allows me to con¬ 
tinue to contribute to the worldwide community of 
computer users. The community has been fostered 
by UNIX and also by the growth of the network, in 
which I have played a part. 

In a world where corporate interests dominate 
the future of UNIX, USENIX has a vital independent 
role. The Association is adapting well to the 
differing needs of old and new members; careful, 
rather than radical, evolution seems to be the key to 
success. 

Why should a foreigner run for USENIX? 
USENIX is not just a North American organization 
- approximately 15% of the membership are not US 
or Canadian citizens. I have been a USENIX 
member since 1977. Originally I was the institu¬ 
tional representative for the University of Kent. I 
am now an individual member. 

Won’t a foreigner be costly to transport to 
board meetings? No, it can cost less to fly from 
London into an international US airport than it 
does to fly from one US coast to another. 

What can a foreigner do for USENIX? I believe 
I can bring a fresh and informed perspective to the 
administration of the Association. My EUUG ex¬ 
perience has been very relevant at the board meet¬ 
ings I have attended, Dallas 1988 and Washington 
1990. I enjoy being involved with running User 
Groups - and I am good at it. 
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Candidate for Director 


Dr. Daniel £. Geer, Jr. 



Biographical Information 

S.B., 1972, Electrical Engineering and Computer 
Science, Massachusetts Institute of Technology, 
Cambridge, Mass.; Sc.D., 1988, Biostatistics, 
Epidemiology, and Artificial Intelligence, Harvard 
University, School of Public Health, Cambridge, 
Mass. 

Member: Association for Computing 

Machinery (1975), Massachusetts Public Health As¬ 
sociation (1978), American Public Health Associa¬ 
tion (1980), American Association for Artificial In¬ 
telligence (1980), Biometrics Society (1981), Society 
for Industrial & Applied Mathematics (1981), 
American Statistical Association (1981), Society for 
Medical Decision Making (1983), USENIX Associa¬ 
tion (1985), (Session Chair 2/88; Tutorial Instructor 
6/88, 2/89, 7/89; Program Committee 10/89-1/90; 
Session Chair 1/90), Society for Artificial Intel¬ 
ligence and Statistics (1988). 

For over four years, I have led the Systems 
Development group at MIT’s Project Athena in the 
design, implementation, and propagation of the 
world’s largest centrally managed, vendor neutral, 
scalable distributed computing environment. The 
design requirements of that effort led directly to a 
UNIX-based solution, and have allowed me to 
demonstrate my leadership abilities as we have 
moved a large university from departmental time¬ 
sharing to a network services model of computa¬ 
tion. Our software, such as the X Window System 
and the Kerberos network authentication system, 
are now ubiquitous in the UNIX community. The 
rest of my 20 years of experience is in the area of 
medical, clinical, and statistical computing, areas 
where there exist significant opportunities for the 
expansion of the UNIX environment, and where I 
have particular expertise. My chief technical in¬ 
terests are computing in the large, wide area 
systems administration, computer assisted coopera¬ 
tive work, and (software tools for) multimedia 
workstations. 


Position Statement 

My interest in the Board of Directors is natural: 
USENIX is the single organization with both the 
longstanding commitment to open systems and the 
technical throw-weight to make the right things hap¬ 
pen. My various past USENIX activities as an 
author/presenter, Program Committee member, Ses¬ 
sion Chair, Tutorial Speaker, and BOF convener il¬ 
lustrate my involvement with UNIX issues, and my 
role as the principal technical speaker to the roughly 
2500 visitors Project Athena entertains annually in¬ 
dicates my commitment to expanding and improv¬ 
ing the UNIX universe. I believe my experience and 
vision can serve the USENIX organization well as 
UNIX grows in the 1990s. I would very much 
appreciate your support, and pledge the kind of ac¬ 
tivism that takes the long range view. 
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Candidate for Director 


Ed Gould 


Biographical Information 

For the last seven years, I have been working at MT 
Xinu, a Berkeley, California, supplier of BSD- and 
Mach-based operating system software, mt Xinu is, 
among other things, employee owned and dedicated 
to employee management. Prior to co-founding MT 
Xinu in 1983, I was a member of the technical staff 
of the Computer Center of the University of Cali¬ 
fornia at Berkeley, where I did software develop¬ 
ment for a home-grown variant of the operating 
system for a CDC 6400 and, starting in 1976, 
software development and systems administration 
for a collection of UNIX systems. After leaving 
U.C. in 1982, I managed UNIX systems and did 
software development for two R&D groups at Na¬ 
tional Semiconductor Corporation. 

Position Statement 

I have been attending UNIX Users’ conferences 
since 1977, before the current USENIX Association 
was formally incorporated. Over that time, I have 
seen the organization grow from an ad-hoc collec¬ 
tion of (mostly) kernel hackers getting together to 
discuss which bugs they had each tripped over and 
fixed, to a moderately large, professionally-run or¬ 
ganization serving a diverse community. 

As the community of UNIX Users has grown 
and diversified, so has the membership of USENIX. 
The membership has an ever-growing set of needs 
that the organization might choose to address. One 
of the primary challenges facing USENIX over the 
coming years is to balance maintaining the level of 
technical content in its conferences and publications 
against recognizing that more and more of the 
membership consists of people new to the UNIX 
system. 

I would like to see the organization continue to 
grow—not necessarily in size, but as a provider of 
services to its membership. We have seen interest¬ 
ing changes over the last few years, including the 
inauguration of Computing Systems and the in¬ 
crease in the number of workshops and the atten¬ 
dance at the workshops. The experiment of having 
a track of what I like to call "‘nuts and bolts” ses¬ 
sions running in parallel with the traditional 
research-oriented track was a great success. More 



such sessions at future conferences look to be a 
wonderful way to include more of the membership 
into the main stream of the conferences. 

In general, I see USENIX as an organization 
whose purpose consists largely of two related items. 
First is education. It’s clear that one of the major 
purposes for attending a USENIX conference is to 
take the tutorials. The tutorial program has been 
well run and the tutorials themselves have been of 
high quality. We need to maintain at least the 
current level of tutorial offerings, and increase those 
offerings whenever the combination of interest, 
qualified speakers, and space are available. 

Second, the Association is a vehicle for 
disseminating information about happenings in the 
UNIX community, and for fostering communication 
among users. In recent years, there has been a 
strong emphasis on research-oriented presentations 
at conferences. While research topics are important 
and of continuing interest to much of the member¬ 
ship, there is a large—and growing—segment of the 
USENIX audience that can be better served by 
presentations with more day-to-day value. Also, 
with the increasing penetration of network connec¬ 
tivity, due in part to the success of the USENIX- 
sponsored UUNET experiment, some of the com¬ 
munications functions that the Association has 
served in the past are being well-served by other 
means. USENIX needs to continue to explore new 
ways to facilitate communication among the UNIX 
community. 

Another avenue that I think would be good for 
USENIX to pursue is that of encouraging creativity 
and new ideas within the community. To this end, 

I would like to encourage presentations about other 
operating systems—both commercial systems 
(successes and failures, current and historical) and 
research projects—at USENIX conferences. To some 
degree, the Association has already ventured into 
this area, particularly in the workshop it recently 
co-sponsored with ACM and SERC on Distributed 
and Multiprocessor Systems. I would like to see 
continued emphasis on variety in the programming 
of the conferences. 
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Candidate for Director 


Daniel V. Klein 


Biographical Information 

I am currently employed by the Software Engineer¬ 
ing Institute in Pittsburgh. I hold a Masters of Sci¬ 
ence in Applied Mathematics from Camegie-Mellon 
University, and as an employee of the University, 
served for 4 years as Chairman of both the Staff 
Council and University Grievance Review Board. I 
have been attending USENIX conferences for 10 
years, and have been working with the association 
since 1984. I was technical program chair for the 
Winter ’90 Conference. 

Position Statement 

My goals as a director of the USENIX Association 
are simple, and can be listed in two short items. 

1. USENIX needs to foster quality in publications 
and research. We as an association need to keep 
the level of technical excellence of the conferences 
and of the work that we fund at a high level. The 
work we present at conferences needs to be both in¬ 
teresting and worthwhile. UNIX and the members 
of USENIX are all changing, and we as an organiza¬ 
tion need to grow with them. 

2. USENIX needs to continue to attract new peo¬ 
ple. I do not mean that we need to grow just for 
the sake of growing. What we do need to do is con¬ 
tinue to keep the Association, its conferences, and 
workshops enticing for both our existing member¬ 
ship and for potential new members. As we as a 
community grow, it essential for our personal 
development to continue to meet with new people, 
to see new work, to generate new ideas, and to stay 
abreast of the new developments in our field. 



When I chaired the D.C. conference, I set out 
to satisfy these two goals. We tried to attract new 
people - the alternate sessions were a first pass at 
broadening the appeal of USENIX; we maintained a 
high level of technical content, although much of 
this credit goes to the authors themselves; and 
finally, we provided an entertaining and stimulating 
environment in which to acquire the information 
available at the conference. I have a very strong 
committment to the organization, and want to do 
even more. Your vote will enable me to do so. 


March/April 1990 


13 


Candidate for Director 


Evi Nemeth 


Biographical Information 

Evi Nemeth earned her undergraduate degree in 
Mathematics from Penn State University and Ph.D. 
degree, also in Mathematics, from the University of 
Waterloo in Ontario, Canada. She joined the Com¬ 
puter Science faculty at the University of Colorado 
in 1981 and has helped expand the UNIX facility 
there from a single PDP 11/70 to its present 
configuration of over 100 machines which serve the 
research and instructional needs of thousands of 
students. Evi is currently on one semester leave 
from CU to teach at Dartmouth College in Han¬ 
over, New Hampshire. 

Evi has been involved with UNIX since Version 
6 days, though often more as a political ally than as 
a developer. Evi instigated the use of UNIX in the 
SUNY system in New York state and later at the 
University of Colorado. She is a co-author (with 
two of her students) of The UNIX System Adminis¬ 
tration Handbook (Prentice Hall, 1989), has pro¬ 
duced the Proceedings for almost all recent USENIX 
Conferences, and has taught several USENIX tutori¬ 
als. 

Position Statement 

Universities and students have always had a special 
symbiosis with UNIX and USENIX. Even today as 
the system makes its way into the commercial 
world, universities — Berkeley, Utah, CMU, MIT 
and others — continue to push the technical state of 
the art and contribute new ideas and utility. 

One of my goals is to see the Association con¬ 
tinue to maintain strong ties to universities and to 
students. I also hope to influence the Association to 
continue the innovation which enables it to serve all 
its members: not only wizards and gurus but also 
newcomers — the future lifeblood of the organiza¬ 
tion. To this end, I will support programs like the 
alternate track of non-research talks that was so well 
received at the recent conference in Washington, 
D.C. 
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Candidate for Director 


Sonya D. Neufer 


Biographical Information 

Sonya Neufer received her Bachelor’s degree in 
Computer Science from the University of Califor¬ 
nia, San Diego. While there, she worked for the 
Computer Science department as an assistant to the 
systems administrator. She also assisted in the 
development and instruction of a new undergradu¬ 
ate course which taught the basics of UNIX to 
computer-naive undergraduates. She went on to 
work for Datapoint where she introduced UNIX 
into their proprietary systems environment. This 
grew into a position as lead technical advisor for 
Datapoint’s introduction of UNIX into its product 
line. From there she was transferred to Datapoint’s 
Canadian Development office to assist in the imple¬ 
mentation of UNIX-compatible networking software 
for Datapoint’s proprietary RMS Operating System. 
She is now working as a systems analyst for 
Canstar, a company that does software design and 
development for fiber-optic networks. Sonya organ¬ 
ized and ran the Terminal room at the San Diego, 
Baltimore, and Washington USENIX Conferences. 

Position Statement 

The evolution of the USENIX Association over the 
last ten years has been outstanding. The attendance 
at technical conferences is growing as UNIX catches 
on in ever more diverse environments. As these en¬ 
vironments grow, the Association must grow with 
them, making sure the technical content at our 
conferences maintains its high standards. We are 
getting better formal papers, now we need to con¬ 
centrate our efforts on the new informal (con¬ 
current) sessions to interest more of our members 
while retaining serious technical content. 

I believe that as we approach 1992, USENIX 
should encourage closer participation from similar 
international organizations. Considering the 
number of common interests that are shared 
between EUUG, AUUG, and USENIX there are many 
avenues of cooperation that need to be explored. 
As well, with the new freedoms in the eastern bloc, 
groups there are showing a growing UNIX member¬ 
ship which should be welcomed as well. 



Student participation in the USENIX Associa¬ 
tion is growing, but more work is necessary to 
encourage students wishing to learn about the tech¬ 
nical venues available. Student grants have helped 
university students in attending conferences, but 
more needs to be done to promote active student 
participation. 

I have enjoyed working with the USENIX Asso¬ 
ciation organizing and running the Terminal room 
at the last three conferences. I hope that I will be 
able to expand my participation into other areas as 
a member of the Board of Directors. 
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Candidate for Director 


Barry Shein 



Biographical Information 

President, Software Tool & Die 

I have been an active member of USENIX for 
several years, most recently as co-chair of the 
USENIX Software Management Workshop. I have 
been involved with UNIX for over 13 years, going 
back to the early V6 days when I used UNIX for 
real-time programming in medical research at Har¬ 
vard. 

In 1983 I became the first member of the 
Distributed Systems Group at Boston University 
and was charged with supporting UNIX and creating 
a campus-wide network. During that time I was 
also a graduate student and lecturer in their com¬ 
puter science department. I founded and I am 
currently president of Software Tool & Die, 
purveyors to the trade. 

Recently I created The Online Book Initiative, 
a public-spirited project committed to providing 
freely redistributable online books and other texts. 
I am technical editor for Sun/Expert magazine, a 
frequent contributor to the Connexions internet¬ 
working journal and have worked on and created 
software which is in common use in our community 
(xman, Franz Lisp, Macsyma, the cypress network 
etc.). I have published many technical articles relat¬ 
ing to UNIX, including a recent paper at this past 
summer USENIX. 

Moreover, I know what I am getting into 
(somewhat); 1 have spent the past two years on the 
board of directors of the Sun Users Group and have 
served as treasurer and secretary for that organiza¬ 
tion. I am not a stranger to the very pragmatic 
responsibilities of running a user group. 

Position Statement 

In today's rapidly changing world many of us are 
concerned with finding a continuing role for 
USENIX. UNIX was once a maverick operating 
system whose primary use seemed to be annoying 
the status quo. Everyone owned the sources (full 
source only cost $60 in those halcyon days) and 


much of the UNIX community made fundamental 
modifications to the system itself. 

USENIX’s role in all this was providing a meet¬ 
ing place where those maverick kernel gurus ex¬ 
changed ideas. Today UNIX has become main¬ 
stream and is even threatening to become the status 
quo. Today a much smaller percentage of people 
who use UNIX own the sources, let alone have any 
interest in modifying their systems as radically as 
we did. 

But technology continues to advance at a 
breathtaking pace and fundamental issues of how to 
adapt UNIX to that changing technology remain. 
We have seen the growth of other UNIX user groups 
with missions to cater to commercial and new users. 
I don’t think USENIX’s role has changed much in all 
this clamor, nor should it. 

I see USENIX’s purpose as twofold: First, to 
provide the means for members of the UNIX com¬ 
munity to communicate with each other and, 
second, to be a place where we can get together and 
influence the future of UNIX. 

Concern for the future of UNIX is what makes 
USENIX unique among the many user groups. It is 
the organization you come to when you want to find 
out what might be happening in the next several 
years or want to sound out a few new ideas of your 
own. This is a critical role and I intend to see 
USENIX continue to be vital as an organization 
which provides innovative channels of communica¬ 
tion for those who shape the future of UNIX. 
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Candidate for Director 


Dave Taylor 


Biographical Information 

Currently President of Intuitive Systems, a consult¬ 
ing firm specializing in user interface design, 
software marketing strategies and internationaliza¬ 
tion, Mr. Taylor started in the computer field with a 
degree in Computer Science from the University of 
California at San Diego in 1984. During that time, 
he was an employee of Logicon T&TSD in San 
Diego. Following that, he began as a technical staff 
member at Hewlett-Packard Colorado Networks 
Operation in Fort Collins, Colorado in 1984. Fol¬ 
lowing a year and a half of PC networking, and on 
the strength of his concurrent software development 
in the UNIX environment, Mr. Taylor accepted a 
position as a research scientist at HP Laboratories 
in Palo Alto, California. While at HP Labs he 
released the Elm Mail System to the UNIX public, 
as well as work on remote mail aliases, a sendmail 
verification suite, and similar. In early 1988 he 
moved into the HP University Grants Program as 
Technical Project Leader, and helped steer the 
group to such important research projects as Mach, 
Andrew, and Sprite. In late 1988 he resigned from 
Hewlett-Packard to form Intuitive Systems, and has 
since consulted with Hewlett-Packard, Apple Com¬ 
puter, Sun Microsystems, the Whole Earth ’Lec- 
tronic Link, Merit Software, Artecon, and similar. 

In addition to his work with computer 
programming and marketing, Mr. Taylor has 
published well over 100 articles in trade journals, 
and has played a key role in the publication of two 
books. Currently he is on the editorial staff of “The 
Sun Observer,” “The HP Chronicle,” “HP/Apollo 
Workstation,” and “Computer Language,” as well 
as being UNIX columnist for “Computer Currents,” 
a free regional newspaper. 

USENIX related experience includes founding 
the Tutorial Evaluation Committee and being the 
only non-USENIX board member on the committee, 
as well as having been on the program committee of 
a USENIX Technical Conference in 1987. 

Position Statement 

As a professional journalist, it is clear to me that 
the “mission” of the USENIX Association is one of 
communication, or information dissemination. 
This is a two-way street, and if we consider much of 
the success of the Association, I believe we'll 



consistently find that the highest rated activities are 
those that disseminate key UNIX related informa¬ 
tion to the members. For example, consider the 
dramatic growth of the specialized topic symposia; 
when I became active in the USENIX Association al¬ 
most seven years ago, the only events I can recall 
being sponsored were the two technical conferences 
each year. Now, through focusing on the value of 
smaller, more narrow topic meetings, there are over 
a half-dozen symposia each year, all well attended, 
and all offering information - and personal con¬ 
tacts - not easily available anywhere else. 

To me, then, the key challenge that the Associa¬ 
tion has to face is how to continue to offer the in¬ 
valuable information to the members in the face of 
the dramatically evolving UNIX marketplace, as 
well as with the encroaching competition of Uni- 
Forum and other vendor specific user groups. (The 
best way to deal with this particular challenge is to 
work with the other groups, and as a member of 
UniForum, the Sun Users Group, and the HP IN- 
TEREX Users Group, I am also well positioned to 
aid in inter-group communication too.) 

Additionally, as a Member at Large, I believe 
that my role is best described as an information 
funnel, not only to help members understand what 
is going on with the board of directors, but, much 
more importantly, to aid the board members in 
understanding what the views and ideas of the 
members are. With that in mind, I think it’s vitally 
important for a Member at Large to be a current 
participant on Usenet and accessible via electronic 
mail, since these are clearly the most popular vehi¬ 
cles for communication in the technical UNIX com¬ 
munity. 

Finally, I’ll wrap up by simply stating that 
while it’s important that USENIX retain the techni¬ 
cal orientation that it started with, and that we hew 
out a niche for ourselves in the expanding UNIX 
marketplace, it's perhaps just as important that we 
have some fun in the process! I can’t offer you a 
chicken in every pot or two cars in every garage, but 
I can promise that we’ll continue to grow and learn 
more about UNIX every year and have an enjoyable 
time doing it! 
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Candidate for Director 


Alix Meredith Vasilatos 


Biographical Information 

A.B. (Economics) Vassar College, 1979; Ph.D. 
program (Marxian Economics) University of 
Massachusetts at Amherst, 1979-82. 

UNIX Distributed Services and Systems Administra¬ 
tion person since 1981, at Harvard, BBN, GTE 
Labs, MIT Project Athena, and OSF. Many papers 
and talks on using UNIX, systems administration, 
and distributed services. 

USENIX activities: 

• Attendee, all but one conference since Boston 
1982, plus some workshops. 

• Co-chair, Large Installation Systems Adminis¬ 
tration Workshop, 1987. 

• Chair, Large Installation Systems Administra¬ 
tion Workshop II, 1988. 

• Informal Program Chair, Baltimore 1989 Sum¬ 
mer Conference. 

• Chair, Large Installation Systems Administra¬ 
tion Workshop II, 1989. 

• Program Committee, Washington D.C. 1990 
Winter Conference. 

Position Statement 

I may be an atypical person, but in a typically 
technoid way, I am happy when the UNIX com¬ 
munity is comfortably and creatively computing 
and cogitating along. I am trying hard to fix it so 
that everyone who wants to help sustain the kind of 
USENIX we like and want can do so (by putting in 
straightforward procedures that make it easy to 
“jump in" with contributions of ideas, time, special 
talents, and comradelmess). 



The key is information exchange, facilitated by 
USENIX on paper, USENIX on the networks, 
USENIX at conferences: folks communicating tech¬ 
nical ideas everywhere, every way. USENIX can 
publish works that will inform the brainstorming 
that everyone building a new facility or a new ser¬ 
vice goes through. USENIX can help support public 
access systems with sufficient connectivity that we 
can experiment with more nontraditional (noncor¬ 
porate, nonacademic, nondefense) participation in 
electronic mail, Usenet news, access to free 
software, free text, library indices and other data¬ 
bases, multi-media projects, and programming. 

We of USENIX have been helping make things 
happen all along and it has been A Good Thing. 
Having helped out with USENIX workshops, confer¬ 
ences, committees, and miscellany for a few years, 
I’d like to help even more, in a more integrated 
way, to do what we have to do to make sure that 
our community grows - as it must - coherently, 
creatively, and collectively. Me, I’m wicked 
psyched. 
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Call for Papers: UNIX Security Workshop 

Marriott Hotel, Portland, OR, August 27-28, 1990 


The Second UNIX Security Workshop is 
to be held in Portland, Oregon, on Monday 
and Tuesday, August 27 and 28, 1990. Matt 
Bishop will again be chairing this workshop. 
It will bring together researchers in computer 
security dealing with UNIX and system ad¬ 
ministrators trying to use UNIX in environ¬ 
ments where protection and security are of vi¬ 
tal importance. It is intended to provide an 
environment where researchers can discuss 
their latest results, where researchers and prac¬ 
titioners can discuss the applicability of those 
results to practical problems, and where 
system administrators can share their unique 
solutions and techniques for dealing with 
problems. The topics covered by this 
workshop include both theoretical topics and 
everyday problems. We expect each par¬ 
ticipant to present unique attributes of his/her 
environment and/or research and contribute a 
short (five minute) discussion (and paper) 
detailing some result or solution from their en¬ 
vironment or work. 

Some topics to be considered include: 

modeling the UNIX operating system 
theoretically 

password security (password file integrity, 
enforcing choice of a safe password, 
spotting and handling crackers) 
network security (problems arising from logins 
over an unprotected Ethernet, containing 
a break-in to one machine in a networked 
environment) 

security in a distributed system or 
environment 

file system security (auditing packages, security 
in an NFS environment) 
computer worms, viruses, and other 
phenomena 

new designs to obtain C-level (or better) 
certification 

making existing UNIX systems more secure, 
and locating and fixing UNIX security 
problems 

any other problem or contribution that 
participants make. 


Workshop Format 

This gathering will follow a “workshop” 
format rather than a “paper presentation” for¬ 
mat. Please submit a one or two page sum¬ 
mary describing a problem and, if you have 
one, a solution, or if not, a possible approach 
or approaches which looked promising but 
failed (or which you have not yet tried). Also, 
be sure to include with your submission a set 
of five (or so) topics that you’d like to hear 
about. It is possible that some participants 
will not present their papers at this workshop. 

The workshop chairman will collate the 
papers to schedule sessions which have 
appropriate audiences. It is anticipated that 
some sessions will include all participants 
though others may require breaking into 
smaller groups. Send your submissions to the 
address below by May 22, 1990. 

For further information, contact: 

Matt Bishop 

Dept, of Mathematics and Computer Science 
Bradley Hall 
Dartmouth College 
Hanover, NH 03755 

(603) 646-3267 

decvax!dartvax!Matt.Bishop 

Matt.Bishop@dartmouth.edu 
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Call for Papers: Mach Workshop 

Radisson Hotel, Burlington, VT, October 4-5,1990 


The use of Mach in what has traditionally 
been the UNIX community is growing as 
DARPA and OSF increase their Mach-related 
activities and more vendors are supporting 
Mach on a variety of platforms. Because 
Mach itself is changing rapidly and there 
hasn’t been any convenient mechanism for 
communication among developers, the 
USENIX Association is pleased to sponsor its 
first Mach workshop, in which researchers, 
vendors, and users can share results of Mach- 
related development work and status reports 
on work-in-progress. 

The workshop will be oriented towards 
those who have actually worked with Mach or 
have done Mach-based applications develop¬ 
ment, and will not be tutorial in nature. The 
program will consist largely of refereed papers 
and panels. Abstracts of 350-700 words 
should be sent to the program chair at the ad¬ 
dress below (those submitting hardcopy 


abstracts should send five copies). The dead¬ 
line for submissions is June 22, 1990. All sub¬ 
missions will be acknowledged. Authors will be 
notified by July 20, 1990, and full papers will 
be required by August 27, 1990. 

For further information about the 
workshop, contact the program chair: 

Melinda Shore 
mt Xinu 

2560 Ninth St., Suite 312 
Berkeley, CA 94710 

(415) 644-0146 
shore@mtxinu.com 

Program Committee: 

Alan Langerman, Encore Computer Corporation 
Douglas Orr, Camegie-Mellon University 
Homayoon Taj alii, Trusted Information Sys. 
Avadis Tevanian, NeXT, Inc. 


Call for Papers: IEEE Reliable Distributed Systems Workshop 
Huntsville, AL, October 11-12, 1990 


With the sponsorship of the technical 
committee on Distributed Processing of the 
IEEE Computer Society and in cooperation 
with the USENIX Association, a workshop on 
Experimental Distributed Systems will be held 
on October 11-12, 1990 in Huntsville, Ala¬ 
bama in conjunction with the Ninth IEEE 
Symposium on Reliable Distributed Systems 
(see page 54 of IEEE Computer , January, 
1990). 

The workshop will cover experiences, per¬ 
formance, and observations obtained from 
current efforts in distributed systems around 
the world in academia and industry. A similar 
workshop was held in October 1986 and 
resulted in a special issue of IEEE Transaction 
on Software Engineering (June 1989). 

Please submit 10 copies of a 2 page ex¬ 
tended abstract to 

Professor Bharat Bhargava 
Department of Computer Science 


Purdue University 

West Lafayette, IN 47906 USA 

(317) 494-6013 
bb@cs.purdue.edu 

by April 10, 1990. This abstract will be used 
to invite speakers and participants to this 
limited attendance workshop. The program 
committee for the workshop is as follows: Cal- 
ton Pu (Columbia), Ken Birman (Cornell), Sat- 
ish Tripathi (Maryland), George Leach 
(AT&T, Paradyne), Gene Spafford (Purdue), 
John Riedl (Minnesota), Prasun Dewan (Pur¬ 
due), Kane Kim (UC-Irvine), Terje Fallmyr 
(Univ. of Tromso, Norway), Roger Shultz 
(Rockwell Inti.), Yousef Khalidi (Sun 
Microsystems), and Hugh Lauer (Kodak). 

Papers based on the submission and 
workshop will be considered for publication in 
the newsletter of the Technical Committee on 
Distributed Processing, Proceedings of the 
workshop, and a special issue of a journal. 
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Call for Papers: 

Large Installation Systems Administration Conference 

Colorado Springs, CO, October 17-19, 1990 


The Fourth USENIX Large Installation 
Systems Administration Conference will be 
held in Colorado Springs, Colorado on 
October 18-19, 1990. A tutorial program will 
be offered in conjunction with the conference 
on October 17. 

The program committee will be reviewing 
papers submitted on subjects including but not 
limited to: 

Automation of tasks 
Network management 
Distributed services 
System backup 
File and data archiving 
Electronic mail 
Security 

Account/user management 

Accounting 

USENET News/Notes 

Performance monitoring and tuning 

Configuration management 

Vendor issues 

Distributed administration 

We are especially interested in papers which 
provide freely available or fully described solu¬ 
tions to existing problems, or which in some 
way advance the state of the art. Administra¬ 
tion of installations which are “unique” in any 
fashion (size, hardware, number of users, 
security level, etc.) is also of special interest. 


Papers should be from 5 to 15 pages in 
length, including diagrams, figures, etc. Papers 
should include a brief description of the site, 
an outline of the problem and issues, and a 
description of the solution. We prefer, but do 
not require electronic form, e.g., nroff/troff, 
TeX, Postscript, etc. 

Workshop proceedings will be distributed to 
all the attendees and are also available after 
the Conference from the USENIX Association. 

The deadline for submission of papers is 
July 25,1990. 

For further information about the conference, 
contact the program chair: 

Steve Simmons 

Industrial Technology Institute 
2901 Hubbard Road 
Ann Arbor, MI 48109 

313-769-4086 

scs@iti.org 
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Call for Papers: EUUG Conference 


October 22-26, 1990, Nice, France 

The Autumn 1990 European UNIX 
systems User Group Technical Conference will 
be held October 22-26, 1990, at the Nice 
Acropolis, Nice, France. Technical tutorials 
on UNIX and closely related subjects will be 
held on October 22-23, followed by the three 
day conference with a commercial exhibition. 

Call for Papers 

The EUUG invites papers from those 
wishing to present their work. Full papers or 
extended abstracts must be submitted. All 
submitted papers will be refereed and judged 
with respect to their quality, originality, and 
relevance. 

Suggested subject areas include, but are 
not limited to: 

• Software management for large projects 

Configuration management 
Maintenance management 
Update and release control 

• OS1 and OSI application on a UNIX platform 

• System administration in a heterogeneous 
environment 

• Security and audit 

Secure UNIX 

Securing existing systems 

• UNIX in non-English speaking environments 

• User Interface management systems 

Submissions from students are particularly 
encouraged under the EUUG Student 
Encouragement Scheme, details of which are 
available from the EUUG Secretariat. 

Important Dates 

Abstract deadline 
Acceptance notification 
Final paper received 
Student Grant Applications 
deadline 

Method of Submission 

Full papers or extended abstracts must be 
submitted by post to the EUUG Secretariat 
and, if possible, in electronic form to 
euug-nice@eu.net. All submissions will be ack¬ 
nowledged by return of post. 


Guidance to Authors 

A copy of the EUUG guidance to Authors 
will be sent automatically to everybody that 
submits a paper. It will also be printed in the 
Spring edition of the EUUG newsletter. 

Tutorial Solicitation 

Tutorials are an important part of the 
EUUG’s biannual events providing detailed 
coverage of a number of topics. Past tutorials 
have been taught by leading experts. 

We are keen to provide classes to all lev¬ 
els. Those interested in offering a tutorial 
should contact the EUUG Tutorial Executive 
as soon as possible. 

Additional Information 

We will be pleased to provide advice to 
potential speakers, and can be contacted at the 
addresses below. 

If you wish receive further information 
about this and future EUUG events, please 
write, or send electronic mail, to the 
Secretariat. 

EUUG Secretariat 
Owles Hall 
Owles Lane 

Buntingford, Herts SG9 9PL UK 

Phone: (+44) 763 73039 
Fax: (+44) 763 73255 

Email: euug@eu.net 

Conference & Tutorial Executive 
Neil Todd 
GiD Ltd 

Email: neil@gid.co.uk 

Program Chair 
Johan Helsingius 
OY Penetron Ab 
Email: julf@fuug.fi 

Program Committee 

Pierre Louise Neumann INRIA France 

Dr. Elod Knuth MTA SZTAKI, Hungary 

Daniel Klein CMU, USA 


April 30, 1990 
May 10, 1990 
June 30, 1990 

Sept. 1, 1990 
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Long-Term Calendar of UNIX Events* 

1990 Apr 9 

POSIX APP Workshop 

NIST; Gaithersburg, MD 

1990 Apr 9-11 

USENIX C++ Conference 

San Francisco, CA 

1990 Apr 23-27 

EUUG 

Munich, Germany 

1990 Apr 23-27 

IEEE 1003 

Salt Lake City, UT 

1990 May 7-11 

DECUS 

New Orleans, LA 

1990 May 17 

U & Parallel Systems, NLUUG 

Ede, Netherlands 

1990 May 30-Jun 1 

UNIX/90 

/usr/group/cdn; Toronto, Ont. 

1990 Jun 11-15 

USENIX 

Marriott Hotel, Anaheim, CA 

1990 Jun 11-15 

ISO WG15 (POSIX) 

Paris, France 

1990 Jul 9-11 

15th JUS Symposium 

Tokyo, Japan 

1990 Jul 11-13 

UKUUG 

London, UK 

1990 Jul 16-20 

IEEE 1003 

Danvers, MA 

1990 Jul 17-19 

UniForum 

Washington, DC 

1990 Aug 20-23 

Interex 

Boston, MA 

1990 Aug 27-28 

* Security 

Portland, OR 

1990 Sep 4-5 

GUUG 

Wiesbaden, Germany 

1990 Sep 25-28 

AUUG 

World Congress Centre, Melbourne, Aust. 

1990 Oct 4-5 

*Mach 

Burlington, VT 

1990 Oct 17-19 

* Large Installation Sys. Admin. 

Colorado Springs, CO 

1990 Oct 8-12 

InterOp 90 ACE 

San Jose, CA 

1990 Oct 15-19 

IEEE 1003 

Seattle, WA 

1990 Oct 22-26 

EUUG 

Nice, France 

1990 Oct 31-Nov 1 

UNIX Expo 

New York, NY 

1990 Nov 5-9 

Computer Communication Conf. 

ICCC; New Delhi, India 

1990 Nov 8 

Open Systems, NLUUG 

Ede, Netherlands 

1990 Nov 14-16 

UNIX EXPO ’90 UniForum 

Stockholm, Sweden 

1990 Nov 15 

POSIX APP Workshop 

NIST; Gaithersburg, MD 

1990 Nov 15-16 

16th JUS Symposium 

Osaka, Japan 

1990 Dec 4-5 

JUS UNIX Fair ’90 

Tokyo, Japan 

1990 Dec 10-12 

UNIX Asia ’90 

Sinix, Singapore 

1990 Dec 10-14 

DECUS 

Las Vegas, NV 

1991 Jan 7-11 

IEEE 1003 

New Orleans, LA 

1991 Jan 16-18 

* Software Devel. Environments 

Grand Kempinski, Dallas, TX 

1991 Jan 21-25 

USENIX 

Grand Kempinski, Dallas, TX 

1991 Jan 22-25 

UniForum 

Infomart, Dallas, TX 

1991 Feb 

UNIX in Government 

Ottawa, Ont. 

1991 Feb 18-22 

DECUS 

Ottawa, Ont. 

1991 May 

UNIX 8x/etc 

/usr/group/cdn; Toronto, Ont. 

1991 May 6-10 

DECUS 

Atlanta, GA 

1991 May 20-24 

EUUG 

Tromso, Norway 

1991 Jun 10-14 

USENIX 

Opryland, Nashville, TN 

1991 Jun/Jul 

UKUUG 

Liverpool, UK 

1991 Sep 16-20 

EUUG 

Budapest, Hungary 

1991 Dec 

UKUUG 

Edinburgh, UK 

1991 Dec 9-13 

DECUS 

Anaheim, CA 

1992 Jan 20-24 

USENIX 

Hilton Square, San Francisco, CA 

1992 Jan 21-24 

UniForum 

Moscone Center, San Francisco, CA 

1992 Spring 

EUUG 

Jersey, UK 

1992 May 4-8 

DECUS 

Atlanta, GA 

1992 Jun 8-12 

USENIX 

Marriott, San Antonio, TX 

1992 Autumn 

EUUG 

Amsterdam, Netherlands 

t Compiled with ihe assistance of Alain Williams of the EUUG, Susanne Smith of Windsound Consulting and John 

Quarlerman of Texas Internet Consulting. 

* USENIX Workshops 
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Book Review 

The Design and Implementation of the 
4.3BSD UNIX Operating System 
Leffler, McKusick, Karels, & Quarterman 

(Addison-Wesley, 1989) 

Reviewed by Sunil K. Das 

City University London Computer Science 

Department 

This learned volume presents knowledge 
about the Berkeley variant of the UNIX operat¬ 
ing system previously unavailable in one text. 
The four authors are known within the UNIX 
community for their expert computing skills, 
articulate conference presentations, and the 
quality of their written technical papers. It is 
therefore, difficult to imagine the book being 
anything other than very good. 

John Lions in Australia documented the 
internals of 6th Edition UNIX as long ago as 
1977, but the 4.3BSD book will ultimately be 
considered alongside Maury Bach’s account of 
System V.2 internals, 1 which is possibly 
unwise since their target audiences are 
different. By some quirk of fate both books 
are 471 pages long, with the V.2 account being 
aimed at introducing readers to operating 
systems at a first level, while the 4.3BSD text 
provides a natural progression and addresses a 
more knowledgeable, second level, advanced 
scholar. 

The layout of this book provides a sensi¬ 
ble way to document a process-based operating 
system. It commences with an excellent four 
page Preface giving a concise account of the 
material covered, its applicability to academic 
courses and the overall organization. It is 
structured into five parts and further subdi¬ 
vided into chapters: 

1. Overview - History and Goals, Design 
Overview of 4.3BSD, Kernel Services 

2. Processes - Process Management, Memory 
Management 

1 M. J. Bach, The Design of the UNIX Operating System , 
Prentice-Hall, Englewood Cliffs, NJ (1986). 


3. I/O System - I/O System Overview, The 
File System, Device Drivers, Terminal Han¬ 
dling 

4. Interprocess Communication - Interpro¬ 
cess Communication, Network Communica¬ 
tion, Network Protocols 

5. System Operation - System Startup 

Graded exercises appear at the end of 
each chapter which range from testing the 
reader’s knowledge of what has appeared in 
the text to presenting major design projects or 
open research questions. References for the 
chapter follow the exercises and there is an 
extensive Glossary and Index at the end of the 
book. 

The book is enjoyable to read, with a very 
direct style. Periodically, the style does drift a 
little, which is not surprising with four 
authors, but this does not detract from its rea¬ 
dability. There are lengthy descriptions of 
algorithms, and text with only a few sentences 
being difficult to understand. My suspicion is 
that these instances occur because the book is 
written by Americans for a US market or 
maybe I simply didn’t understand the few sen¬ 
tences. 

A useful perspective is gained from the 
discussion about the internals of early versions 
of UNIX. Since UNIX has evolved with the 
hardware, it is possible to see why some 
redundant code exists in UNIX, namely, for 
historical reasons and/or backwards compati¬ 
bility. Moreover, as well as concentrating on 
an implementation description, the text 
discusses and details the reasoning behind the 
design of 4.3BSD. It not only gives an in-depth 
description of how things work, but more 
importantly, we are told why things are there. 

My perception was that the 4.3BSD book, 
compared with the V.2 text, had fewer 
diagrams, fewer algorithms and concentrated 
on the written word. However, the informa¬ 
tion has been collected together into a 
coherent structure. In particular, having the 
details of the “fast file system” in one place, 
especially the part on file system data 
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fragmentation, is very helpful. I now under¬ 
stand something that gave me difficulty before. 
Conversely, 4.3BSD does not have a distributed 
file system and I believe an omission is that 
there is no discussion on Sun NFS which is so 
widely accepted. I appreciate that Sun NFS is 
not part of 4.3BSD, but it is difficult to 
separate them nowadays. 

Networking (Part 4) is the least 
understood aspect of BSD UNIX, so a descrip¬ 
tion of the ideas behind mapping protocols 
into the kernel would have proved useful. In 
fact, the way this part of the book is written 
gives the impression that networking evolved 
into the kernel. We all know that networking 
was “hacked” into the socket mechanism and 
not designed into the kernel. Furthermore, the 
Interprocess Communication chapter “dives 
in” at a very low level of detail rather than 
discussing the principles of networking. I 
found that what has been written did not 
relate to the kernel. This part of the text has 
not evolved into the book like other subjects, 
where principles and implementations have 
been discussed in parallel. 


The account centers upon the VAX 
hardware so I was dubious about the useful¬ 
ness of the memory management section. VAX 
memory management is quite dated which 
necessarily affects the discussion. The text will 
be read by kernel gurus and system program¬ 
mers, among others, whose typical usage might 
be to read parts of the book followed by read¬ 
ing some source code. This is fine if you have 
“vanilla” 4.3BSD and a VAX, but the book 
won’t cope so well for those with different 
hardware. However, you can’t “please all of 
the people all of the time.” 

In summary, the text is comprehensive 
with one or two omissions - no Sun NFS 
discussion and no discussion on further 
memory management techniques expected to 
be found on different versions of BSD4.3. It is 
the memory management unit rather than the 
VAX that we need to know about. However, 
the book is invaluable to anyone working with 
operating systems. It enables him or her to see 
the design philosophies behind the construc¬ 
tion of a real operating system. One can 
understand from reading this book how a real 
operating system works and how to “color” 
the operating system to suit the hardware. 


USENIX Seeks an Editor 

The USENIX Board of Directors, at its 
January meeting (see page 29), decided to be¬ 
gin publishing books, as a natural extension of 
the Association’s already considerable publish¬ 
ing program (conference and workshop 
proceedings, manuals, ;login:, and Computing 
Systems ). 

To that end the Association is seeking 
candidates to fill the position of Book Editor. 
The editor will have the support of an editorial 
board and a managing editor, and will estab¬ 
lish, together with the publications committee 


of the USENIX Board of Directors, an editorial 
policy and a review process much as was done 
for the Journal. (The position of Editor will 
be remunerated.) 

All parties interested in the position of 
Editor should send their resumes and a 500 
word statement to the Executive Director as 
soon as possible, for circulation to the editor 
search committee. Deadline for submission of 
application is April 30, 1990. 
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Electronic Communications Privacy Act 

Dan Appelman 

Heller, Ehrman, White and McAuliffe 

The last question asked at the panel on Ethics in the Computer Industry at the USENIX confer¬ 
ence in Washington D.C. in January had to do with the relevance of the Electronic Communications 
Privacy Act to the discussion of ethical standards. The question did not get an adequate response. 
Dan Appelman, one of the panelists and legal counsel for the USENIX Association, briefly describes 
that Act below. If, as a result of this description, there is a response from the readers for a more 
detailed explanation of the Act, Dan has agreed to supply one in a future issue of ;login:. 


The Electronic Communications Privacy 
Act of 1986, signed into law on October 26th 
of that year, is an important piece of legisla¬ 
tion for those in the computer industry. It was 
one of the first attempts of the Federal govern¬ 
ment to regulate acts interfering with elec¬ 
tronic messaging. It is comprehensive and 
complex and impossible to summarize well in 
a few short paragraphs. Nevertheless, here are 
some of its features: 

• The Act makes it illegal to intercept, 
review or disclose the contents of, log initia¬ 
tion and termination information about, or 
otherwise use certain kinds of electronic com¬ 
munications absent the consent of the sender 
or the recipient. 

• The Act makes it illegal to gain 
unauthorized access to electronic communica¬ 
tion services and to exceed an existing authori¬ 
zation to access such services. 

• The Act places restrictions on communi¬ 
cation service providers and gives them certain 
obligations to ensure the privacy of communi¬ 
cations between senders and recipients. 

• The Act creates both civil and criminal 
causes of action for violations. On the civil 
side, those injured may sue in Federal court. 
Remedies include injunctions, money dam¬ 
ages, punitive damages, attorneys fees and 
costs of suit. The Act also enables the U.S. 
Justice Department to bring criminal actions 
against violators. Penalties range from six 
months to five years in jail and fines up to 
$250,000 depending on the nature of the viola¬ 
tion. 


Most of the cases citing the Act have 
looked at whether the government exceeded its 
authority in intercepting communications by 
wire tap. A few others involved private suits 
against communications service providers for 
providing services in such a way that message 
content was available indiscriminately to third 
parties. In each of these, the court decided 
that the allegations of illegal conduct were 
beyond the scope of the Act, and the service 
provider was found to have operated within 
the law. The case law interpreting the Act does 
not yet include instances where hackers have 
been sued or indicted for illegally intercepting 
electronic communications. 

The Act itself does address some of the ac¬ 
tivities which were mentioned during the panel 
discussion on Ethics in the Computer Industry 
in Washington D.C. However, as I said then, 
there is an important distinction between legal 
and ethical constraints. The law, this law in¬ 
cluded, describes certain minimum standards 
of behavior which society will tolerate and im¬ 
poses sanctions for their violation. Ethical 
standards are imposed, usually self-imposed, 
on groups which are professional subsets of 
society. These professions use altogether 
different standards in describing acceptable 
behavior than do lawmakers, and there is often 
no penalty for their violation. The Electronic 
Communications Privacy Act of 1986 tells us 
what is illegal behavior, but it does not help us 
to define what is ethical behavior. The ques¬ 
tion posed by the panel remains, of course, 
open. 
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Best Student Paper 

The Program Committee for the Washington, D.C. Technical Conference has named 
“Disk Scheduling Revisited” by Margo Seltzer, Peter Chen, and John Ousterhout of Univer¬ 
sity of California, Berkeley, the best student paper presented at that conference. An award 
of $500 was presented to the student authors, Margo Seltzer and Peter Chen. 


USENIX Scholarship 

In order to further the study of portable operating systems, the USENIX Association 
will again award a graduate scholarship for the 1990-91 academic year. 

The award is for $5000, with no strings attached. 

Applicants should be currently enrolled in a graduate program at an accredited post¬ 
secondary institution involved in computer research. 

Applicants should send a one page summary of their research, along with their most 
recent transcript (forwarded directly by the official Registrar of the enrolling institution), and 
three letters of recommendation, one of which should be from the professor directing the 
student’s work. Applications should be sent to: 

Ellie Young 
Executive Director 
USENIX Association 
2560 Ninth St., Suite 215 
Berkeley, CA 94710 

Last date for applications is April 30, 1990. The award will be announced at the USENIX 
Summer Conference. 

PLEASE BRING THIS TO THE ATTENTION OF POTENTIALLY INTERESTED 
STUDENTS. Prior scholarship holders have been from Columbia, U. of Washington, and 
MIT; the current awardee is James Griffioen at Purdue University. 


Work-in-Progress Report: Washington, D.C. 

There was only one work-in-progress presentation at the Winter 1990 USENIX Confer¬ 
ence. For those of you who were not present, here’s the abstract. 

CCL - An Interactive Shell Based Upon the C Language 

Mark Roschke, Los Alamos National Laboratory 

Current UNIX shells utilize little C syntax beyond C expressions. CCL is a general pur¬ 
pose shell written to take advantage of many of the familiar aspects of the C language while 
maintaining a high degree of interactivity. A wide range of features of the C programming 
paradigm are provided, including programs, functions, control flow statements, and expres¬ 
sions. This allows the user to draw upon experience with the C language, thereby allowing 
the user to focus on the aspects of the shell not found in C, such as process control and in¬ 
teractivity. 
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New Association President 

Alan G. Nemeth 

At the USENIX Board of Directors meet¬ 
ing in January, I resigned from the Presidency 
of the Association. A number of questions 
have since been raised about my resignation, 
and I would like to clarify what I did and why. 

I have been President of the Association 
since June, 1984, and a director of the Asso¬ 
ciation since June, 1982. This has been a 
period of extensive growth in the marketplace 
for the UNIX operating system (dare I say - 
the open systems market). I took the role of 
President with a desire to transition the Asso¬ 
ciation from a forum for discussion of techni¬ 
cal issues by a small number of dedicated 
technologists to a professional society with a 
more rigorous approach to evaluating and 
presenting the continuing technical work of its 
members. It was clear in 1984 that the 
number of individuals who would be par¬ 
ticipating was going to grow - the question 
was how to channel that growth into higher 
quality without losing the informal communi¬ 
cation and debate that has been a hallmark of 
the UNIX community from the beginning. 

Overall, I am highly satisfied with the way 
the Association has developed. I needed and 
received the assistance of a large number of 
talented people who have been generous with 
their time and their opinions. Without the 
energy and wisdom they provided, the Asso¬ 
ciation would be a much less interesting organ¬ 
ization, and could easily have lost the sense of 
community - the training and helping of oth¬ 
ers that is a distinguishing characteristic. 

It is time for me to retire from the 
Presidency and give others with their own vi¬ 
sion for the next stage of the Association’s life 
a chance to again change the character of the 
organization. Accordingly, I decided not to 
run in the upcoming election. You are for¬ 
tunate to have two excellent candidates for the 


office of the Presidency in Kirk McKusick and 
Steve Johnson - it is up to you as a group to 
decide whose version of the Association is 
more to your liking. You also have the good 
fortune to have an excellent slate of candidates 
for the other Board seats - listen carefully to 
their different views as you file your ballots. 

During the entire term of my Presidency, 
one of the most valuable members of the 
Board was the Vice President, Ms. Deborah 
Scherrer. Debbie has been on the Board of the 
Association since June, 1980, and Vice 
President since June, 1984. She has 
shouldered more than her share of the tasks of 
running the Association. Debbie has given ex¬ 
tensively of her time, her wisdom, and her joy 
to make the Association a special organization. 
Without her assistance, my role would have 
been much more difficult. Debbie has also de¬ 
cided that she will not be a candidate in the 
current election to allow others their own op¬ 
portunity to drive the Association. 

Once it was clear that neither Debbie nor 
I would be continuing on the Board past June, 
I felt that I would like to take the opportunity 
to honor Debbie’s contribution in a way that 
only I could do. By resigning the Presidency, 
Debbie automatically became President by the 
terms of our bylaws for the remainder of her 
term on the Board. I saw no conflict with the 
current election since Debbie and I had both 
declared our intentions clearly. In January, I 
announced my decision - first privately to 
Debbie, then to the Board of Directors, and 
publicly at the Open Meeting with the Board. 
I retain my role as a director of the Associa¬ 
tion until the new Board takes office following 
the June conference. 

I would like to ask you all to assist in 
thanking Debbie for the excellent work she has 
done for so long. 
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Summary of Board of Directors’ Meeting 

Washington, D.C, January 21 and 22, 1990 


Attendance: Stephen C. Johnson, Rob 

Kolstad, Marshall Kirk McKusick, Sharon 
Murrel, Michael D. O’Dell, Alan G. Nemeth, 
John S. Quarterman, Deborah K. Scherrer, 
Ellie Young, Judith DesHamais, John L. 
Donnelly, Daniel Klein, John Mashey, Carolyn 
Carr, Eric Allman, Alain Henon, Smoot Carl- 
Mitchell, Kurt Baumann, Shane McCarron, 
Dominic Dunlop, Peter Collinson, Alix 
Vasilatos, Evi Nemeth, Rick Adams, Ed 
Gould, Sonya Neufer, Barry Shein, Dave 
Taylor, Philip Peake, Neil Todd, Greg Rose. 

Nemeth welcomed the board nominees 
who were attending the meeting. 

Action Items 

DesHamais reported that she had received 
31 requests for information on daycare ser¬ 
vices at the D.C. conference. Donnelly said 
that the posting on the net for participation in 
the Speakers Bureau had generated 21 
responses so far. 

D.C. ’90 Conference 

Klein felt that one of the reasons for 
better papers at this conference may have been 
the extended abstracts requirement, which 
made it easier to select. It was reported that 
80% of the 16 tutorials being offered were full, 
expected total attendance was 1500, and seven 
talks had been scheduled for the new con¬ 
current sessions. 

Anaheim ’90 Conference 

John Mashey reported that the Call for 
Papers included more directions for submis¬ 
sions, which he hoped would enable the com¬ 
mittee to have better, but possibly fewer 
abstracts. He is looking for a higher percen¬ 
tage of reflective papers as an experiment. 

Professional Development Seminars 

Donnelly said that local user group par¬ 
ticipation is probably essential, and for the 
upcoming one in Houston, the HOUNIX group 
is involved. We would evaluate how this one 
goes at the Spring board meeting before decid¬ 
ing on whether to budget for more seminars 
this fiscal year. 


Graphics V Workshop 

Young reported that there were 64 paid 
attendees. Johnson commented that there 
were two really outstanding papers, and 
perhaps the workshop was misnamed. 

Future Workshops 

Young had requested proposals to chair 
the next Large Installation Systems Admin, 
workshop. It was agreed we would be a 
cooperative sponsor for an IEEE workshop on 
experimental distributed systems. 

Book Publishing Proposal 

The proposal was based upon the notion 
that USENIX would undertake a series of 
publications, whereby we would underwrite 
the risk of publishing books that might not be 
financially viable to other publishers. There 
was considerable sentiment in favor of 
USENIX extending its already considerable 
publishing program to include books. It was 
decided to allocate funds to pursue this 
proposal. A committee was formed to oversee 
this activity, and the board would consider 
editorial policy and publisher issues at future 
meetings. 

4.4BSD Manuals Proposal 

McKusick went over the proposal from 
the Computer Systems Research Group of UC 
Berkeley to produce system documentation for 
the 4.4BSD release incorporating the POSIX 
and ANSI C standards, an enhanced standard¬ 
ized manual page format with site specific font 
choice and several other features, which for 
the first time would be distributable, in printed 
or source form, without restriction. He ex¬ 
plained that they will release two different 
tapes: 1) complete 4.4BSD and 2) another sub¬ 
distribution with everything that requires an 
AT&T license removed. There ensued a discus¬ 
sion about whether to invest in making materi¬ 
als AT&T-free, and whether our role as manu¬ 
als distributor is still a service to the com¬ 
munity. After more discussion, it was agreed 
that at this time we would fund Phase I of the 
proposal which covers copy editing and 
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clerical support for the project, and consider 
printing and distribution at a later date. 

Nemeth pointed out that each of the 
proposals has a component of a board member 
benefitting in some way, and that a possible 
conflict of interest may be buried in each of 
them. Young would request legal counsel to 
give us a written opinion on the question of 
what kinds of conflict of interest rules we 
should put into place. 

Matrix, Inc. Proposal 

Matrix, Inc. asked the USENIX board to 
fund a prototype of a project that will collect, 
edit and distribute information about com¬ 
puter networks worldwide similar to that in 
Quarterman’s book, The Matrix. After much 
discussion, it was decided that when balancing 
the cost of it with the benefit to our member¬ 
ship, the cost was too much for what we get. 

UUCP Report 

Johnson summarized his findings and pos¬ 
sible reasons for why USENIX might want to 
be involved: 

1) services were going downhill rapidly and 
becoming a source of confusion in the environ¬ 
ment. 

2) there are overt administrative problems 

3) the discussion on the net had to do with 
protocols and getting it done. 

4) how do you package it? 

There are a lot of technical and ad¬ 
ministrative issues as yet to be resolved, e.g., 
how to distribute it? He had received many 
suggestions such as lobbying AT&T to do it, 
that USENIX should buy something and put it 
into public domain, etc. 

There ensued a fountain of suggestions. 
Johnson then outlined the following: 

1) protocols are old 

2) broken implementation (e.g., way necessary 
information is filed and stored) 

3) different on every system 

4) PC and Mac interfaces 

5) administrative interface 

6) anonymous ftp 

Should we give this back to someone as a 
request for implementation? Johnson men¬ 
tioned that there is a package being worked on 


by UUNET for release in the Fall that might 
help. Adams said he is working on a protocol 
compatible program, and would report on his 
progress at the Fall board meeting. Nemeth 
said that Adam’s offer may not resolve this 
issue. 

Kolstad attempted to make a motion to 
table the discussion. However, discussion con¬ 
tinued regarding possible ways for checking 
out implementation. Nemeth asked if there is 
something useful that we could do in the fu¬ 
ture? Johnson felt that this discussion has led 
to some ideas but the original thrust of why 
USENIX should be involved, has gone no¬ 
where. No one else volunteered to work on 
this project and the discussion was tabled. 

Journal Report 

O’Dell reported that the next two issues 
were in progress. One would contain the best 
papers from the USENIX Distributed & Mul¬ 
tiprocessor Systems workshop. The other 
would have a collection of papers on music. It 
was agreed to allocate funds for the production 
of a compact disk in this issue. 

Proposal to Offer Discounts to Membership 

It was agreed that a non-member rate 
should be reflected for those who wish to pur¬ 
chase proceedings. Young’s proposal to raise 
the workshop registration fee for non-members 
to $240 (with a checkoff option to become a 
member) was approved. It was also agreed 
that funds be allocated to aid students who 
wish to attend workshops. 

Tutorial Compensation Committee Report 

The committee reported it had looked ifito 
possible changes in what we pay tutorial 
speakers. It was felt that while we do not have 
a problem attracting new tutorial speakers, 
there is a problem of retaining our long-term 
presenters, and a compensation scheme tied to 
longevity was appropriate. It was agreed that 
the compensation currently set at $2,000 per 
tutorial be set at $2,000 for the first three tu¬ 
torials given by a speaker (by speaker and not 
by topic), and thereafter $3,000 per tutorial 
would apply. In the case of two speakers, a 
blended rate would would calculated. This 
scheme would go into effect with the Anaheim 
conference. 
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Board Election 

Young reported on the calendar of events, 
and was asked to post the candidates’ state¬ 
ments on the net. Taylor advocated using 
USENET as a forum for the candidates. Most 
felt that this was inappropriate and that the 
candidates be contacted individually via 
e-mail. 

ISO Monitoring Project Proposal 

It was agreed that we allocate funds to 
support this WG15 activity in 1990 with the 
expectation of matching funds being provided 
by EUUG. 

Standards Liaison Proposal 

Quarterman felt the proposal would put 
the USENIX standards activities on a firm 
financial footing. Johnson asked if funding 
standards activities is within the Association’s 
charter? Quarterman stressed that our moni¬ 
toring standards activities is important so that 
innovation is not prohibited. (See page 33 of 
this issue.) It was agreed that while Quarter- 
man has performed volunteer standards liaison 
work for USENIX in the past, he can no 
longer handle this task for free in the future. 
After much discussion about the value of con¬ 
tinuing this activity, it was agreed that we in¬ 
crease our current budget for additional sup¬ 
port of standards activities and allocation of 
funds be overseen by a subcommittee of 
McKusick and Young. 

Standards Workshop Proposal 

McCarron’s proposal for a joint IEEE / 
USENIX Standards Workshop, with possible 
participation by EUUG and UniForum was 


approved. He explained that two major areas 
would need to be addressed: Programming to 
Standards and Selecting Standards required for 
Applications, and that the intended audience 
would be application developers and software 
managers. 

World UNIX Users Group 

Dunlop’s interest in forming such a group 
is that it would enable us to have a more cred¬ 
ible representation to ISO. It was decided to 
empower a committee (Quarterman as chair 
with Nemeth and Murrel) to investigate the 
feasibility of creating and/or joining an inter¬ 
national body to foster effective technical 
representation in standards. 

Collinson and Kolstad suggested the ways 
to better convey what is going on at the 
workshops, and Young would implement 
them. 

Next Board Meeting 

It will be held in Berkeley, California on 
April 5 and 6. The first day would be a long- 
range planning meeting, followed by a regular 
meeting on the second. All nominees would 
be invited. 

Bylaw Issue 

Nemeth expressed his intention to resign 
from the presidency of the Association and re¬ 
tain his position as a Director of the Associa¬ 
tion until the end of the elected term in June, 
1990. (See page 28 of this issue.) In accor¬ 
dance with the Association bylaws section 
4.1.4 the Vice President automatically be¬ 
comes the President. 

-EY 


Writers & Book Reviewers Sought for Our Newsletter 


The Association would like to invite in¬ 
terested folks to suggest topics and columns, to 
submit their papers, and to serve as book 
reviewers to ;login If you have a paper that 
you would like published, or a topic that needs 
to be circulated, please let us know. ;login: is 
your newsletter and we can only make it more 
interesting and viable if we have contributions 
from you, the members. 


If you are willing to volunteer to write a 
column on “current events,” “tips ’n hints,” 
serve as a book reviewer, or want to get a 
message out to the other USENIX members, 
the Editor (ellie@usenix.org) would like to 
hear from you. 

-EY 
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Survey of Computing Systems 

Peter H. Salus 

Managing Editor 

There were several comments on Computing Systems listed in the 1989 Member Survey 
published in the last issue of ;login:. I think it appropriate for me to respond to them. 

First of all, though, Mike O’Dell and I would like to thank most of you for your plau¬ 
dits and enthusiasm. Without your help and encouragement, we’d never have been able to 
make Computing Systems a success. 

A volume devoted to a particular topic. 

Issue 3.1 of Computing Systems will be devoted to such a single topic - music. This 
has been in the works for over a year. More such issues will occur in the future, but 
there’s a great deal of coordination which goes into this. 

Articles that elaborate on papers from conferences. 

If we take this as “conferences and workshops,” then issue 3.2 will be such an issue, 
containing elaborations of papers from the Distributed and Multiprocessor Systems 
Workshop held last autumn in Florida. Without an extraordinary effort on the part 
of Gene Spafford, this could not have come about. 

More articles that include graphics/illustrations. 

There’s lots of this in the next two issues, but we can only print what’s submitted. 
See my general comment. 

More how to/applied articles. 

There are some in the works. 

More issues! 

It’s really gratifying that folks want more. But one of the requirements for publish¬ 
ing more is having more. My computation for the first two years of the journal is 
that we have published under 20% of the submissions. This may seem very low, but 
it is a tribute to the volunteer readers and to the staff: we could print more, but the 
level of quality would drop. 

General comment: As I said in both San Francisco and San Diego at the Conferences, 
USENIX is a volunteer organization. If you don’t write and submit stuff, there will be no 
conference papers, no workshops, no .login:, no Computing Systems. And if the quality of 
what’s submitted is low, the quality of the product drops or there are fewer pages printed. If 
you want a special issue of the journal on, say, X.500, then propose it and get a bunch of 
your buddies to commit to writing stuff on it. If you want more items containing graphics, 
generate submissions containing them. Mike O’Dell and I can’t create contents. I think that 
the first 10 issues of Computing Systems have been extraordinary. If you want this to con¬ 
tinue, it’s up to you. 
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An Update on UNIX and C Standards Activity 

Jeffrey S. Haemer 

Report Editor, USENIX Standards Watchdog Committee 


USENIX Standards Watchdog Committee 

The reports that accompany this summary are 
for the Fall meeting of IEEE 1003 and IEEE 
1201, conducted the week of October 16-20, 
1989, in Brussels, Belgium. (This isn’t really 
true of the 1003.4 and 1003.8/1 reports, but 
let’s overlook that.) 

The reports are done quarterly, for the 
USENIX Association, by volunteers from the 
individual standards committees. The 
volunteers are familiarly known as “snitches” 
and the reports as “snitch reports.” The band 
of snitches and I make up the working com¬ 
mittee of the USENIX Standards Watchdog 
Committee. The group also has a policy com¬ 
mittee: John S. Quarterman (chair), Alan G. 
Nemeth, and Shane P. McCarron. Our job is 
to let you know about things going on in the 
standards arena that might affect your profes¬ 
sional life - either now or down the road a 
ways. 

More formally: The basic USENIX policy 
regarding standards is: 

to attempt to prevent standards from 

prohibiting innovation. 

To do that, we 

• Collect and publish contextual and techni¬ 
cal information such as the snitch reports that 
otherwise would be lost in committee minutes 
or rationale appendices or would not be 
written down at all. 

• Encourage appropriate people to get 
involved in the standards process. 

• Hold forums such as Birds of a Feather 
(BOF) meetings at conferences. We sponsored 
one workshop on standards. 

• Write and present proposals to standards 
bodies in specific areas. 

• Occasionally sponsor White Papers in par¬ 
ticularly problematical areas, such as IEEE 
1003.7 (in 1989) and possibly IEEE 1201 (in 
1990). 


• Very occasionally lobby organizations that 
oversee standards bodies regarding new com¬ 
mittees, documents, or balloting procedures. 

• Starting in mid-1989, USENIX and EUUG 
(the European UNIX Users Group) began 
sponsoring a joint representative to the 
ISO/IEC JTC1 SC22 WG15 (ISO POSIX) stan¬ 
dards committee. 

There are some things we do not do: 

• We do not form standards committees. 
It’s the USENIX Standards Watchdog Com¬ 
mittee, not the POSIX Watchdog Committee, 
not part of POSIX, and not limited to POSIX. 

• We do not promote standards. 

• We do not endorse standards. 

Occasionally we may ask snitches to 
present proposals or argue positions on behalf 
of USENIX. They are not required to do so 
and cannot do so unless asked by the USENIX 
Standards Watchdog Policy Committee. 

Snitches mostly report. We also 
encourage them to recommend actions for 
USENIX to take. 

John S. Quarterman, Chair 
USENIX Standards Watchdog Committee 

We don’t yet have active snitches for all 
the committees and sometimes have to beat 
the bushes for new snitches when old ones 
retire or can’t make a meeting, but the number 
of groups with active snitches is growing 
steadily. This quarter, you’ve seen reports 
from .1, .4, .5, .6, .8/2, and a belated report of 
last quarter’s .8/1 meeting, as well as a report 
from 1201. Reports from .2 and .7 are in the 
pipeline, and may get posted before this sum¬ 
mary does. We have no reports from .3, 
.8/[3-6], .9, .10, or .11, even though we asked 
Santa for these reports for Christmas. 

If you have comments or suggestions, or 
are interested in snitching for any group, 
please contact me (jsh@usenix.org ) or John 
( jsq@usenix.org ). If you want to make 
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suggestions in person, both of us go to the 
POSIX meetings. The next set will be January 
8-12, at the Hotel Intercontinental in New 
Orleans, Louisiana. Meetings after that will be 
April 23-27, 1990 in Salt Lake City, Utah, and 
July 16-20, 1990 in Danvers (Boston), 

Massachusetts. 

I’ve appended some editorial commentary 
on problems I see facing each group. I’ve 
emphasized non-technical problems, which are 
unlikely to appear in the official minutes and 
mailings of the committees. If the comments 
for a particular group move you to read a 
snitch report that you wouldn’t have read oth¬ 
erwise, they’ve served their purpose. Be 
warned, however, that when you read the 
snitch report, you may discover that the 
snitch’s opinion differs completely from mine. 

Report on 1003.0 

Outside of dot zero, this group is referred to as 
“the group that lets marketing participate in 
POSIX.” Meetings seem to be dominated by 
representatives from upper management of 
large and influential organizations; there are 
plenty of tailor-made suits, and few of the 
jeans and T-shirts that abound in a dot one or 
dot two meeting. There’s a good chance that 
reading this is making you nervous; that you’re 
thinking, “Uh, oh. I’ll bet the meetings have a 
lot of politics, positioning, and discussion 
about ‘potential direction.’” Correct. This 
group carries all the baggage, good and bad, 
that you’d expect by looking at it. 

For example, their official job is to pro¬ 
duce the “POSIX Guide:” a document to help 
those seeking a path through the open-systems 
standards maze. Realistically, if the IEEE had 
just hired a standards expert who wrote well to 
produce the guide, it would be done, and both 
cleaner and shorter than the current draft. 

Moreover, because dot zero can see the 
entire open systems standards activities as a 
whole, they have a lot of influence in what new 
areas POSIX addresses. Unfortunately, politics 
sometimes has a heavy hand. The last two 
groups whose creation dot zero recommended 
were 1201 and the internationalization study 
group. There’s widespread sentiment, outside 
of each group (and, in the case of internation¬ 
alization, inside of the group), that these 


groups were created at the wrong time, for the 
wrong reason, and should be dissolved, but 
won’t be. And sometimes, you can find the 
group discussing areas about which they 
appear to have little technical expertise. Meet¬ 
ing before last, dot zero spent an uncomfort¬ 
able amount of time arguing about graphics 
primitives. 

That’s the predictable bad side. The good 
side? Frankly, these folks provide immense 
credibility and widespread support for POSIX. 
If dot zero didn’t exist, the only way for some 
of the most important people and organiza¬ 
tions in the POSIX effort to participate would 
be in a more technical group, where the nar¬ 
row focus would block the broad overview that 
these folks need, and which doing the guide 
provides. 

In fact, from here it looks as though it 
would be beneficial to POSIX to have dot zero 
actually do more, not less, than it’s doing. For 
example, if dot five is ever going to have much 
impact in the Ada community, someone’s 
going to have to explain to that community 
why POSIX is important, and why they should 
pay more attention to it. That’s not a job for 
the folks you find in dot five meetings (mostly 
language experts); it’s a job for people who 
wear tailor-made suits; who understand the 
history, the direction, and the importance of 
the open systems effort; and who know 
industry politics. And there are members of 
dot zero who fit that description to a tee. 

Report on 1003.1 

Is dot one still doing anything, now that the 
ugly green book is in print? Absolutely. 

First, it’s moved into maintenance and 
bug-fix mode. It’s working on a pair of exten¬ 
sions to dot 1 (A and B), on re-formatting the 
ugly green book to make the ISO happy, and 
on figuring out how to make the existing stan¬ 
dard language-independent. (The developer, 
he works from sun to sun, but the maintainer’s 
work is never done.) Second, it’s advising 
other groups and helping arbitrate their 
disputes. An example is the recent flap over 
transparent file access, in which the group 
defining the standard (1003.8/1) was told, in 
no uncertain terms, that NFS wouldn’t do, 
because it wasn’t consistent with dot one 
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semantics. One wonders if things like the dot 
six chmod dispute will finally be resolved here 
as well. 

A key to success will be keeping enough of 
the original dot one participants available and 
active to ensure consistency. 

Report on 1003.2 

Dot one standardized the UNIX section two 
and three commands. (Okay, okay. All 
together now: “It’s not UNIX, it’s POSIX. All 
resemblance to any real operating system, liv¬ 
ing or dead, explicit or implied, is purely coin¬ 
cidental.”) Dot two is making a standard for 
UNIX section one commands. Sort of. 

The dot two draft currently in ballot, 
“dot-two classic,” is intended to standardize 
commands that you’d find in shell scripts. 
Unfortunately, if you look at dot-two classic 
you’ll see things missing. In fact, you could 
have a strictly conforming system that would 
be awfully hard to develop software on or port 
software to. To solve this, NIST pressured dot 
two into drawing up a standard for a user por¬ 
tability extension (UPE). The distinction is 
supposed to be that dot-two classic standard¬ 
izes commands necessary for shell script porta¬ 
bility, while the UPE standardizes things that 
are primarily interactive, but aid user portabil¬ 
ity. 

The two documents have some strategic 
problems. 

• Many folks who developed dot-two classic 
say the UPE is outside of dot two’s charter, 
and won’t participate in the effort. This sort 
of behavior unquestionably harms the UPE. 
Since I predict that the outside world will 
make no distinction between the UPE and the 
rest of the standard, it will actually harm the 
entire dot-two effort. 

• The classification criteria are unconvinc¬ 
ing. nm(l) is in the UPE. Is it really primarily 
used interactively? 

• cc has been renamed c89, and lint may 
become lint89. This is silly and annoying, but 
look on the bright side: at least we can see 
why c89 wasn’t put in the UPE. Had it been, 
it would have had to have a name users 
expected. 


• Who died and left NIST in charge? POSIX 
seems constantly to be doing things that it 
didn’t really want to do because it was afraid 
that if it didn’t, NIST would strike out on its 
own. Others instances are the accelerated 
timetables of .1 and .2, and the creation of 
1003.7 and 1201.) 

• Crucial pieces of software are missing 
from dot two. The largest crevasse is the lack 
of any form of source-code control. People on 
the committee don’t want to suffer through an 
SCCS-RCS debate. POSIX dealt with the cpio- 
tar debate. (It decided not to decide.) POSIX 
dealt with the vi-emacs debate. (The UPE pro¬ 
vides a standard for ex/vi.) POSIX is working 
on the NFS-RFS debate, and a host of others. 
Such resolutions are a part of its responsibility 
and authority. POSIX is even working on the 
Motif-Open/Look debate (whether it should or 
not). 

At the very least, the standard could 
require some sort of source code control, with 
an option specifying which flavor is available. 
Perhaps we could ask NIST to threaten to pro¬ 
vide a specification. 

As a final note, because dot two (collec¬ 
tive) standardizes user-level commands, it 
really can provide practical portability across 
operating systems. Shell scripts written on a 
dot-two-conforming UNIX system should run 
just fine on an MS-DOS system under the MKS 
toolkit. 

Report on 1003.3 

Dot three is writing test assertions for stan¬ 
dards. This means dot three is doing the most 
boring work in the POSIX arena. Oh, shoot, 
that just slipped out. But what’s amazing is 
that the committee members don’t see it as 
boring. In fact, Roger Martin, who, as senior 
representative of the NIST, is surely one of the 
single most influential people in the POSIX 
effort, actually chairs this committee. Maybe 
they know something I don’t. 

Dot three is balloting dot one assertions 
and working on dot two. The process is mov¬ 
ing at standards-committee speed, but has the 
advantage of having prior testing art as a 
touchstone (existing MindCraft, IBM, and 
NIST test work). The dilemma confronting the 
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group is what to do about test work for other 
committees, which are proliferating like 
lagomorphs. Dot three is clearly outnum¬ 
bered, and needs some administrative cavalry 
to come to its rescue. Unless it expands drast¬ 
ically (probably in the form of little subcom¬ 
mittees and a steering committee) or is 
allowed to delegate some of the responsibility 
of generating test assertions to the committees 
generating the standards, it will never finish. 
(“Whew, okay, dot five’s done. Does anyone 
want to volunteer to be a liaison with dot 
thirty-seven?”) 

Report on 1003.4 

Dot four is caught in a trap fashioned by 
evolution. It began as a real-time committee. 
Somehow, it’s metamorphosed into a catch-all, 
“operating-system extensions” committee. 
Several problems have sprung from this. 

• Some of the early proposed extensions 
were probably right for real-time, but aren’t 
general enough to be the right approach at the 
OS level. 

• Pieces of the dot-four document probably 
belong in the the dot one document instead of 
a separate document. Presumably, ISO will 
perform this merge down the road. Should the 
IEEE follow suit? 

• Because the dot-four extensions aren’t as 
firmly based in established UNIX practice as 
the functionality specified in dot one and two, 
debate over how to do things is more heated, 
and the likelihood that the eventual, official, 
standard solution will be an overly complex 
and messy compromise is far higher. For 
example, there is a currently active dispute 
about something as fundamental as how 
threads and signals should interact. 

Unfortunately, all this change has diverted 
attention from a problem that has to be dealt 
with soon - how to guarantee consistency 
between dot four and dot five, the Ada- 
language-binding group. Tasks semantics are 
specified by the Ada language definition. In 
order to get an Ada binding to dot four’s stan¬ 
dard (which someone will have to do), dot 
four’s threads will have to be consistent with 
the way dot five uses tasks in their current 
working document. With dot five’s low 


numbers, the only practical way to ensure this 
seems to be to have dot four aggressively track 
the work of dot five. 

Report on 1003.S 

Dot five is creating an Ada-language binding 
for POSIX. What’s “Ada-language binding” 
mean? Just that an Ada programmer should 
be able to get any functionality provided by 
1003.1 from within an Ada program. (Right 
now, they’re working on an Ada-language 
binding for the dot one standard, but eventu¬ 
ally, they’ll also address other interfaces, 
including those from dot four, dot six, and dot 
eight.) They face at least two kinds of techni¬ 
cal problems and one social one. 

The first technical problem is finding some 
way to express everything in 1003.1 in Ada. 
That’s not always easy, since the section two 
and three commands standardized by dot one 
evolved in a C universe, and the semantics of 
C are sometimes hard to express in Ada, and 
vice-versa. Examples are Ada’s insistence on 
strong typing, which makes things like ioctlQ 
look pretty odd, and Ada’s tasking semantics, 
which require careful thinking about forkQ, 
execQ, and killQ. Luckily, dot five is 
populated by people who are Ada-language 
wizards, and seem to be able to solve these 
problems. One interesting difference between 
dot five and dot nine is that the FORTRAN 
group has chosen to retain the organization of 
the original dot one document so that their 
document can simply point into the ugly green 
book in many cases, whereas dot five chose to 
re-organize wherever it seemed to help the 
flow of their document. It will be interesting 
to see which decision ends up producing the 
most useful document. 

The second technical problem is making 
the solutions look like Ada. For more discus¬ 
sion of this, see the dot-nine (FORTRAN bind¬ 
ings) summary. Again, this is a problem for 
Ada wizards, and dot five can handle it. 

The social problem? Interest in dot five’s 
work, outside of their committee, is low. Ada 
is out-of-favor with most UNIX programmers. 
(“Geez, 1201 is a mess. Their stuff’s gonna 
look as ugly as Ada.”) Conversely, most of the 
Ada community’s not interested in UNIX. 
(“Huh? Another ‘standard’ operating 
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environment? How’s it compare to, say, 
PCTE? No, never mind. Just let me know 
every few years how it’s coming along.”) The 
group that has the hardest problem - welding 
together two, well-developed, standardized, 
disparate universes - has the least help. 

Despite all of this, the standard looks like 
it’s coming close to ballot, which means people 
ought to start paying attention to it before they 
have no choice. 

Report on 1003.6 

Most of the UNIX community would still feel 
more at home at a Rainbow gathering than 
reading the DOD rainbow books. The 
unfamiliar-buzzword frequency at dot six 
(security) meetings is quite high. If you can 
get someone patient to explain some of the 
issues, though, they’re pretty interesting. The 
technical problems they’re solving each boil 
down to thinking through how to graft very 
foreign ideas onto UNIX without damaging it 
beyond recognition. (The recent posting about 
chmod and access control lists, in 
comp.std.unix by Ana Maria de Alvare and 
Mike Ressler, is a wonderful detailed exam¬ 
ple.) 

Dot six’s prominent non-technical 
problem is just as interesting. The government 
has made it clear that vendors who can supply 
a “secure UNIX” will make a lot of money. 
No fools, major vendors have been furiously 
working on implementations. The push to 
provide a POSIX security standard comes at a 
time when these vendors are already quite far 
along in their efforts, but still some way from 
releasing the products. Dot six attendees from 
such corporations can’t say too much, because 
it will give away what they’re doing 
(remember, too, that this is security), but must 
somehow ensure that the standard that 
emerges is compatible with their company’s 
existing, secret implementation. 

Report on 1003.7 

There is no single standard body of practice 
for UNIX system administration, the area dot 
seven is standardizing. Rather than seek a 
compromise, dot seven has decided to re¬ 
invent system administration from scratch. 


This was probably necessary simply because 
there isn’t enough existing practice to 
compromise on. Currently, their intent is to 
provide an object-oriented standard, with 
objects specified in ASN.l and administration 
of a multi-machine networked system as a tar¬ 
get. (This, incidentally, was the recommenda¬ 
tion of a USENIX White Paper on system 
administration by Susanne Smith and John 
Quarterman.) The committee doesn’t have a 
high proportion of full-time system adminis¬ 
trators, or a large body of experience in 
object-oriented programming. It’s essentially 
doing research by committee. Despite this, 
general sentiment outside the committee seems 
to be that it has chosen a reasonable approach, 
but that progress may be slow. 

A big danger is that they’ll end up with a 
fatally flawed solution: lacking good available 
implementations; distinct enough from existing 
practices, where they exist, to hamper adop¬ 
tion; and with no clear-cut advantage to be 
gained by replacing any ad hoc existing solu¬ 
tions except for standard adherence. The stan¬ 
dard could be widely ignored. 

What might prevent that from happening? 
Lots of implementations. Object-oriented 
programming and C++ are fashionable (at the 
1988, Winter Usenix C++ conference, Andrew 
Koenig referred to C++ as a “strongly hyped 
language”); networked UNIX systems are 
ubiquitous in the research community; and 
system administration has the feeling of a 
user-level solvable problem. If dot seven 
(perhaps with the help of dot zero) can publi¬ 
cize their work in the object-oriented program¬ 
ming community, we can expect OOPSLA 
conferences and comp.sources.unix to overflow 
with high-quality, practical, field-tested, 
object-oriented system administration pack¬ 
ages that conform to dot seven. 

Report on 1003.8 

There are two administrative problems facing 
dot eight, the network services group. Both 
stem directly from the nature of the subject. 
There is not yet agreement on how to solve 
either one. 

The first is its continued growth. There is 
now serious talk of making each subgroup a 
full-fledged POSIX committee. Since there are 
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currently six groups (transparent file access, 
network IPC, remote procedure call, OSI/MAP 
services, X.400 mail gateway, and directory 
services), this would increase the number of 
POSIX committees by nearly 50%, and make 
networking the single largest aspect of the stan¬ 
dards work. This, of course, is because stan¬ 
dards are beneficial in operating systems, and 
single-machine applications, but indispensable 
in networking. 

The second is intergroup coordination. 
Each of the subgroups is specialized enough 
that most dot eight members only know what’s 
going on in their own subgroup. But because 
the issues are networking issues, it’s important 
that someone knows enough about what each 
group is doing to prevent duplication of effort 
or glaring omissions. And that’s only a piece 
of the problem. Topics like system adminis¬ 
tration and security are hard enough on a sin¬ 
gle stand-alone machine. In a networked 
world, they’re even harder. Someone needs to 
be doing the system engineering required to 
ensure that all these areas of overlap are 
addressed, addressed exactly once, and com¬ 
pleted in time frames that don’t leave any 
group hanging, awaiting another group’s work. 

The SEC will have to sort out how to solve 
these problems. In the meantime, it would 
certainly help if we had snitches for each sub¬ 
group in dot eight. Any volunteers for .8/[3- 
6 ]? 

Report on 1003.9 

Dot nine, which is providing FORTRAN bind¬ 
ings, is really fun to watch. They’re fairly 
unstructured, and consequently get things done 
at an incredible clip. They’re also friendly; 
when someone new arrives, they actually stop, 
smile, and provide introductions all around. It 
helps that there are only half-a-dozen attendees 
or so, as opposed to the half-a-hundred you 
might see in some of the other groups. Meet¬ 
ings have sort of a “we’re all in this together / 
defenders of the Alamo” atmosphere. 

The group was formed after two separate 
companies independently implemented 
FORTRAN bindings for dot one and presented 
them to the UniForum technical committee on 
supercomputing. None of this, “Let’s consider 
forming a study group to generate a PAR to 


form a committee to think about how we 
might do it,” stuff. This was rapid prototyping 
at the standards level. 

Except for the advantage of being able to 
build on prior art (the two implementations), 
dot nine has the same basic problems that dot 
five has. What did the prior art get them? 
The most interesting thing is that a correct 
FORTRAN binding isn’t the same as a good 
FORTRAN binding. Both groups began by 
creating a binding that paralleled the original 
dot one standard fairly closely. Complaints 
about the occasional non-FORTRANness of the 
result have motivated the group to try to re¬ 
design the bindings to seem “normal” to typi¬ 
cal FORTRAN programmers. As a simple 
example, FORTRAN-77 would certainly allow 
the declaration of a variable in common called 
ERRNO, to hold the error return code. Users, 
however, would find such name misleading; 
integer variables, by default and by conven¬ 
tion, begin with “I” through “N.” 

It is worth noting that dot nine is actually 
providing FORTRAN-77 bindings, and simply 
ignoring FORTRAN-8x. (Who was it that said 
of 8x, “Looks like a nice language. Too bad 
it’s not FORTRAN”?) Currently, 1003 intends 
to move to a language-independent 
specification by the time 8x is done, which, it 
is claimed, will ease the task of creating 8x 
bindings. 

On the surface, it seems logical and 
appealing that documents like 1003.1 be re¬ 
written as a language-independent standard, 
with a separate C-language binding, analogous 
to those of dot five and dot nine. But is it 
really? 

First, it fosters the illusion that POSIX is 
divorced from, and unconstrained by its 
primary implementation language. Should the 
prohibition against null characters in filenames 
be a base-standard restriction or a C-binding 
restriction? 

I’ve seen a dot five committee member 
argue that it’s the former. Looked at in isola¬ 
tion, this is almost sensible. If Ada becomes 
the only language anyone wants to run, yet the 
government still mandates POSIX compliance, 
why should a POSIX implementation prohibit 
its filenames from containing characters that 
aren’t special to Ada? At the same time, every 
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POSIX attendee outside of dot five seems 
repelled by the idea of filenames that contain 
nulls. (Quiz: Can you specify a C-language 
program or shell script that will create a 
filename containing a null?) 

Second, C provides an existing, precise, 
widely-known language in which POSIX can be 
specified. If peculiarities of C make imple¬ 
menting some portions of a standard, specified 
in C, difficult in another language, then there 
are four clear solutions: 

1. change the specification so that it’s equally 
easy in C and in other languages, 

2. change the specification so that it’s 
difficult in every language, 

3. change the specification so that it’s easy in 
some other language but difficult in C, or 

4. make the specification vague enough so 
that it can be done in incompatible (though 
equally easy) ways in each language. 

Only the first option makes sense. Making 
the specification language-independent means 
either using an imprecise language, which risks 
four, or picking some little-known specification 
language (like VDL), which risks two and three. 
Declaring C the specification language does 
limit the useful lifetime of POSIX to the useful 
lifetime of C, but if we don’t think we’ll come 
up with good replacements for both in a few 
decades, we’re facing worse problems than 
language-dependent specifications. 

Last, if you think the standards process is 
slow now, wait until the IEEE tries to find 
committee volunteers who are fluent in both 
UNIX and some language-independent 
specification language. Not only will the use¬ 
ful lifetime of POSIX remain wedded to the 
useful lifetime of C, but both will expire before 
the language-independent version of dot one is 
complete. 

It would be nice if this push for language- 
independent POSIX would go away quietly, but 
it won’t. 

Report on 1003.10 

In July, at the San Jose meeting, John Cay- 
wood of Unisys caught me in the halls and 
said, accusingly, “I understand you think 
supercomputers don’t need a batch facility.” I 


didn’t have the foggiest idea what he was talk¬ 
ing about, but it seemed like as good a chance 
as any to get a tutorial on dot ten, the super¬ 
computing group, so I grabbed it. (Pretty 
aggressively helpful folks in this supercomput¬ 
ing group. If only someone in it could be per¬ 
suaded to file a snitch report.) 

Here’s the story: 

Articles about software engineering like to 
point out that approaches and tools have 
changed from those used twenty years ago; 
computers and computing resources are now 
much cheaper than programmers and their 
time, while twenty years ago the reverse was 
true. These articles are written by people 
who’ve never used a Cray. A typical super¬ 
computer application might run on a S25M, 
non-byte-addressable, non-virtual-memory 
machine, require 100 to 1000 Mbytes of 
memory, and run for 10 Ksecs. Expected run¬ 
ning time for jobs can be greater than the 
machine’s mean-time-to-failure. The same 
techniques that were common twenty years 
ago are still important on these machines, for 
the same reasons - we’re working close to the 
limits of hardware art. 

The card punches are gone, but users 
often still can’t login to the machines directly, 
and must submit jobs through workstation or 
mainframe front ends. Resources are severely 
limited, and access to those resources need to 
be carefully controlled. The two needs that 
surface most often are checkpointing and a 
batch facility. 

Checkpointing lets you re-start a job in 
the middle. If you’ve used five hours of Cray 
time, and need to continue your run for 
another hour but have temporarily run out of 
grant money, you don’t want to start again 
from scratch when the money appears. If 
you’ve used six months of real time running a 
virus-cracking program and the machine goes 
down, you might be willing to lose a few 
hours, even days, of work, but can’t afford to 
lose everything. Checkpointing is a hard 
problem, without a generally agreed-upon solu¬ 
tion. 

A batch facility is easier to provide. Both 
Convex and Cray currently support NQS, a 
public domain network queueing system. The 
product has enough known problems that the 
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group is re-working the facility, but the basic 
model is well-understood, and the committee 
members, both users and vendors, seem to 
want to adopt it. The goal is command-level 
and library-level support for batch queues that 
will provide effective resource management for 
really big jobs. Users will be able to do things 
like submit a job to a large machine through a 
wide-area network, specify the resources - 
memory, disk space, time, tape drives, etc. - 
that the job will need to run to completion, 
and then check back a week or two later to 
find out how far their job’s progressed in the 
queue. 

The group is determined to make rapid 
progress, and to that end is holding 6-7 meet¬ 
ings a year. One other thing: the group is 
actually doing an application profile, not a 
standards document. For an clarification of 
the distinction, see the discussion of dot 
eleven. 

Report on 1003.11 

Dot eleven has begun work on an application 
profile (AP) on transaction processing (TP). An 
AP is a set of pointers into the POSIX Open 
System Environment (OSE). For example, the 
TP AP might say, “For dot eleven confor¬ 
mance, you need to conform to dot one, dot 
four, sections 2.3.7 and 2.3.8 of dot 6, 1003.8 
except for /2, and provide a batch facility as 
specified in the dot 10 AP.” A group doing an 
AP will also look for holes or vague areas in 
the existing standards, as they relate to the 
application area, go point them out to the 
appropriate committee, and possibly chip in to 
help the committee solve them. If they find a 
gap that really doesn’t fall into anyone else’s 
area, they can write a PAR, requesting that the 
SEC (1003’s oversight committee) charter them 
to write a standard to cover it. 

Dot eleven is still in the crucial early stage 
of trying to figure out what it wants to do. 
Because of fundamental differences in philoso¬ 
phy of the members, the group seems to be 
thrashing a lot. There is a clear division 
between folks who want to pick a specific 
model of TP and write an AP to cover it, and 
folks who think a model is a far too detailed 
place to start. The latter group is small, but 
not easily dismissed. 


It will be interesting to see how dot eleven 
breaks this log jam, and what the resolution is. 
As an aside, many of the modelers are from 
the X/OPEN and ISO TP groups, which are 
already pushing specific models of their own; 
this suggests what kinds of models we’re likely 
to get if the modeling majority wins. 

Report on X3J11 

A single individual, Russell Hansberry, is 
blocking the official approval of the ANSI stan¬ 
dard for C on procedural grounds. At some 
point, someone failed to comply with the letter 
of IEEE rules for ballot resolution, and 
Hansberry is using the irregularity to delay 
adoption of the standard. 

This has had an odd effect in the 1003 
committees. No one wants to see something 
like this inflicted on his or her group, so folks 
are being particularly careful to dot all i’s and 
cross all t’s. I say odd because it doesn’t look 
as though Hansberry’s objections will have any 
effect whatsoever on either the standard, or its 
effectiveness. Whether ANSI puts its stamp on 
it or not, every C compiler vendor is imple¬ 
menting the standard, and every book (even 
K&R) is writing to it. X3J11 has replaced one 
de-facto standard with another even stronger 
one. 

Report on 1201.1 

What’s that you say, bunky? Uneasy about 
Xwindows? Well then, you won’t care much 
for 1201.1, which is supposed to be “User 
Interface: Application Programming Inter¬ 
face,” but is really “How much will the Motif 
majority have to compromise with the 
Open/Look minority before force-feeding us a 
thick standard full of ‘Xm[A-Z]...’ functions 
with long names and longer argument lists?” 

Were this group to change its name to 
“Xwindows application programming inter¬ 
face,” you might not hear nearly as much 
grousing from folks outside the working group. 
As it is, the most positive comments you hear 
are, “Well, X is pretty awful, but I guess we’re 
stuck with it,” and “What could they do? If 
POSIX hadn’t undertaken it, NIST would 
have.” 
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If 1201 is to continue to be called “User 
Interface,” these aren’t valid arguments for 
standardizing on X or toolkits derived from it. 
In what sense are we stuck with X? The 
number of X applications is still small, and if 
X and its toolkits aren’t right for the job, it 
will stay small. Graphics hardware will con¬ 
tinue to race ahead, someone smart will show 
us a better way to do graphics, and X will 
become a backwater. If they are right, some 
toolkit will become a de-facto standard, the 
toolkit will mature, and the IEEE can write a 
realistic standard based on it. 

Moreover, if NIST wants to write a stan¬ 
dard based on X, what’s wrong with that? If 
they come up with something that’s important 
in the POSIX world, good for them. ANSI or 
the IEEE can adopt it, the way ANSI’s finally 
getting around to adopting C. If NIST fails, 
it’s not the IEEE’s problem. 


If 1201.1 ignores X and NIST, can it do 
anything? Certainly. The real problem with 
the occasionally asked question, “are standards 
bad?” is that it omits the first word: “When.” 
Asked properly, the answer is, “When they’re 
at the wrong level.” API’s XVT is example of a 
toolkit that sits above libraries like Motif or 
the Mac toolbox, and provides programmers 
with much of the standard functionality 
necessary to write useful applications on a 
wide variety of window systems. Even if XVT 
isn’t the answer, it provides proof by example 
that we can have a window-system- 
independent, application programming inter¬ 
face for windowing systems. 1201.1 could pro¬ 
vide a useful standard at that level. Will it? 
Watch and see. 


Applications Sought for Research Awards 


The UniForum Association is now accept¬ 
ing applications for its new Research Award 
program. Two awards, each of up to two 
years’ duration, and valued at $10,000 per 
year, will be granted annually to graduate 
students. The awards will aid students in 
researching problems concerning UNIX and 
open systems computing. One grant will apply 
to technical study in computer science and the 
other to management sciences as they affect in¬ 
formation management. 

UniForum will give preference to projects 
whose results can be demonstrated at Uni¬ 
Forum Conferences and are of value to its 
sponsors. 

Each recipient of an award must submit a 
one-page status report each quarter, and a 


four-to-five page progress report at the end of 
the first year, which must be approved for the 
award to continue. A formal paper is required 
at the end of the second year and must be 
presented at the UniForum Conference. 

Candidates must apply through their 
university department chair. The deadline for 
departments to submit one or two nomina¬ 
tions for next year is May 1, 1990. Winners 
will be notified on July 1 and their names an¬ 
nounced at the Summer UniForum in Wash¬ 
ington, D.C., later that month. Call the Uni¬ 
Forum Association office at (408) 986-8840 for 
details and applications. Send applications to 
the UniForum Research Award Committee, 
2901 Tasman Drive., #201, Santa Clara, CA 
95054. 
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